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1.  SUMMARY 


This  report  documents  our  findings  concerning  the  feasibility  of  validating  formal  software 
specifications.  This  one  year  effort  attempted  to  show  that  with  a  suitable  formal  software 
specification  language,  specifications  could  be  validated  much  as  implementations  are  currently 
validated,  through  applic  .r.ion  of  testing  methodology. 

This  approach  necessitated  an  "executable"  formal  specification  language  so  that  test  cases  could 
•be  "run"  on  the  specification  itself.  Such  a  language  was  already  under  development  within 
USC/Information  Sciences  Institute.  Our  first  task  was  to  document  this  language  (see  Chapter  2) 
and  our  approach  to  using  it  to  write  forma!  specifications  (see  Chapter  3).  We  then  applied  it  to  three 
real,  moderate-sized  systems  (see  Chapter  4)  to  ensure  that  it  was  suitable  for  military  applications. 
These  experiments  were  highly  successful  in  that  we  were  able  to  formally  specify  the  functional 
behavior  of  these  three  systems 

The  next  major  task  of  this  effort  was  to  demonstrate  that  specifications  in  this  formal  language 
could  be  validated  by  running  them  on  test  data.  Towards  this  end,  we  built  a  prototype  interactive 
testing  facility  called  the  Initial  Operating  Capability  (IOC).  It  consists  of  an  evaluator  capable  of 
executing  specifications  expressed  in  a  subset  of  the  formal  specification  language,  and  an  executive 
for  entering,  editing,  and  displaying  specifications,  for  initializing  the  state  within  which  one  is 
evaluated,  for  displaying  states,  and  for  tracing  and  breakpointing  the  evaluation  interactively  in  a 
DDT. like  manner.  The  IOC  is  described  in  Chapter  5  and  examples  of  its  use  are  given  in  Chapter  6. 

The  final  task  in  this  effort  was  to  design  a  capability  for  testing  a  specification  on  a  whole  class  of 
cases  simultaneously,  rather  than  one  at  a  time,  through  symbolic  execution.  This  design  is 
documented  in  Chapter  7  of  this  report.  It  is  based  on  extending  the  evaluator  to  handle  symbolic  data 
as  well  as  concrete  data,  so  that  as  evaluation  proceeds,  predicates  describing  incompletely  defined 
data  (i.e.,  the  symbolic  data)  are  automatically  constructed  dynamically,  and  wherever 
incompleteness  of  the  data  prevents  determination  of  which  control  path  to  follow,  all  possible  control 
paths  are  explored,  each  conditioned  by  the  predicate  necessary  to  select  it. 

Thus,  there  is  tradeoff  between  breadth  of  test  cases  covered  and  complexity  of  the  symbolic 
evaluation.  For  this  reason,  the  design  allows  the  person  validating  the  specification  to  interactively 
determine  which  data  should  be  concrete  versus  symbolic,  and  hence,  dynamically  define  the  class  of 
test  cases  being  explored. 
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SUMMARY 


The  lollowing  observations  and  conclusions  emerged  from  this  study. 

1.  While  functionally  complete,  the  formal  specifications  omitted  some  aspects  of  the  actual 
systems. 

These  omissions  were  intentional.  We  have  tried  to  prevent  implementation  details  from 
intruding  into  the  formal  specification.  For  that  reason  data  representations  are  not  part 
of  our  specification  language.  This  prevents  us  from  describing  some  (possibly  required) 
aspects  of  the  specified  system,  most  notice^ly  their  I/O  interfaces.  We  believe  these 
(required)  representatives  should  be  documented  -as  part  of  the  chosen  (required) 
implementation  of  the  system,  rather  than  as  part  of  its  specification. 

2.  Existing  specifications  incorporate  implementation  details. 

In  order  to  get  a  good  system  description  for  which  we  could  build  a  formal  specification, 
we  had  to  de  compile  the  existing  description  so  that  it  only  described  the  functionality 
desired,  rather  than  an  implementation  of  it.  As  current  or  former  programmers,  we  are  all 
overly  sensitized  to  efficiency  issues  and  tend  to  describe  a  system  in  terms  of  a  feasible 
(or  possibly  preferred)  implementation.  Representation  issues  are  one  example; 
algorithm  choices  are  another. 

3.  Formal  specifications  are  unreadable. 

This  is  unfortunately  true  for  our  language  as  well  as  all  others.  The  reason  is  that  the 
mechanisms  used  in  informal  communications  to  aid  understanding-such  as  overview, 
summaries,  examples,  elborations,  alternative  viewpoints,  role  descriptions  (why 
something  is  important)- are  totally  missing.  Basically,  no  roadmap  is  provided  to  help 
someone  read  the  specification.  Until  these  issues  are  addressed,  formal  specifications 
will  only  be  understandable  when  accompanied  by  an  informal  natural  language 
description. 

4.  The  formal  specification  language  is  not  interpretable. 

The  reason  is  that  the  formal  specification  language  is  highly  context  dependent  and  this 
context  is  affected  by  many  remote  statements  such  as  type  declarations,  constraints, 
demons,  inference  rules,  action  definitions,  and  individual  uses  of  historical  reference. 
All  these  statements  must  be  located,  collected,  and  "translated"  before  interpretation 
can  begin.  Thus,  the  evaluator  consists  of  a  compiler  which  performs  these  tasks  and  an 
interpreter  which  uses  these  compiled  forms. 

5.  The  evaluator  must  be  interactive. 

The  formal  specification  language  is  highly  non-deterministic  and  the  non-determinism 
interacts  with  the  specified  constraints  so  that  only  those  choices  which  don't  violate 
constraints  either  now  or  in  the  future  are  selected.  Operationally,  the  evaluator  can  only 
discover  the  appropriate  choices  by  trying  them  and  rejecting  those  that  violate 
constraints  anywhere  during  the  evaluation.  This  leads  to  a  classical  backtracking 
search.  To  control  the  size  and  depth  of  this  search  space  during  evaluation,  the  person 
using  the  IOC  can  supply  an  appropriate  choice  rather  than  have  the  evaluator  search  for 
one. 
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2  GIST  SPECIFIER’S  MANUAL 

2.1  INTRODUCTION 

A  Gist  specification  is  a  formal  description  of  valid  behaviors  of  a  system.  This  description  is 
composed  of  three  parts: 

•  A  specification  of  object  types  and  relations  between.these  types.  This  determines  a  set 
of  possible  states.  A  possible  state  consists  of  a  collection  of  objects,  each  of  which  is 
classified  as  an  instance  of  one  or  more  of  the  specified  types.  The  objects  in  a  possible 
state  may  be  related  by  the  specified  relations. 

•  A  specification  of  actions  and  demons,  which  define  transitions  between  possible  states. 

•  A  specification  of  constraints  on  states  and  state  transitions.  The  valid  behaviors  of  a 
system  are  those  defined  transition  sequences  that  do  not  violate  any  constraints. 

This  document  provides  a  tutorial  introduction  to  Gist.  The  concepts  and  syntax  of  Gist  are 
presented  in  the  context  of  describing  the  behavior  of  an  imaginary  system  of  ships  moving  cargos 
among  various  ports. 

A  second  goal  of  this  introduction  is  to  provide  some  insight  into  our  conception  of  "good  taste"  in 
writing  Gist  specifications.  In  Gist,  as  in  programming  languages,  there  are  often  several  ways  to 
specify  the  same  behavior  (functionality).  In  programming  languages,  one  must  make  tradeoffs 
among  understandability  of  code,  modifiability,  and  efficiency.  In  Gist,  efficiency  is  not  an  issue;  there 
IS  no  sense  in  which  two  specifications  of  the  same  behavior  differ  in  efficiency.  The  main  goal  of  the 
specifier  is  to  maximize  h's  confidence  that  he  has  specified  the  intended  behavior.  But  important 
secondary  goals  are  to  make  a  specification  understandable  to  people  other  than  its  creator,  and  to 
make  it  maintainable.  The  rules  of  thumb  and  good  practices  described  are  aimed  at  these  latter 
goals. 

As  v^ith  any  language,  the  use  of  common  conventions  can  itself  improve  communication  between 
people.  But  the  specifier  should  always  remember  that  his  overriding  concern  is  to  be  confident  that 
he  is  specifying  the  behavior  intended. 

While  a  primary  purpose  of  writing  a  specification  is  to  use  it  in  the  process  of  implementing 
computer  software,  there  are  no  software  concepts  within  Gist.  In  particular,  all  behavior  is  specified 
without  the  use  of  the  concepts  of  input/output  or  the  information  representations  available  on  any 
particular  machine  or  in  any  particular  programming  language(s). 
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2.2  TYPES 

The  first  task  of  a  specifier  is  to  decide  on  a  collection  of  object  types  that  will  capture  the  important 
objects,  or  values,  that  the  process  manipulates.  Since  there  is  usually  some  verbal  description  of  the 
process  available,  a  good  rule  of  thumb  is  to  consider  common  nouns  (particularly  concrete  nouns) 
as  the  names  for  object  types. 

Following  this  rule,  even  the  cursory  description  of  our  example  domain  given  earlier  suggests  the 
use  of  ship,  cargo,  and  port  as  object  types. 

The  names  to  be  used  for  object  types  in  Gist  must  appear  in  type  declarations.  The  simplest  form 
of  a  type  declaration  gives  nothing  but  the  name: 

type  ship; 
type  port; 
type  cargo; 

Gist  has  only  a  few  predefined  types.  Among  these  are  number,’  integer,  natnum  (natural 
numbers),  and  character.  These  types  may  be  used  in  a  specification  without  declaration. 
Sometimes  one  of  these  types  is  appropriate,  but  the  specification  would  be  more  natural  if  a  different 
name  were  used.  This  can  be  done  by  defining  a  new  type  name  in  terms  of  an  existing  one: 

type  tonnage  definition  natnum 

The  previous  line  defines  the  type  name  "tonnage"  as  isomorphic  to  the  type  "natnum". 

The  only  reason  to  use  the  predefined  types,  however,  is  to  use  some  capability  that  is  already 
defined  for  them.  The  numerical  types,  for  example,  provide  access  to  arithmetic  operations, 
comparisons,  and  the  ability  to  include  numerical  constants  in  the  specification. 

It  is  a  bad  practice  to  specify  types  to  be  synonyms  for  numbers  because  one  anticipates  the  use  of 
numbers  as  a  representation  in  some  implementation. 

An  enormous  gain  in  expressiveness  is  obtained  by  specifying  supertype  relationships  among 
types.  If  all  objects  of  one  class  also  belong  to  a  second  class,  the  larger  class  should  be  declared  to 
be  a  supertype  of  the  smaller  class: 


’Number  corresponds  to  the  REALS.  It  should  rrot  be  thought  of  as  specifying  "floating  point"  representation  on  a 
computer. 
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type  cargo  unique  supertvpe  gf 

<  grain; 
fuel 

> 

This  declaration  states  that  every  instance  of  cargo  is  an  instance  of  either  grain  or  fuel,  but  not  both. 

In  other  situations,  the  named  subtypes  may  not  e/.'^aust  the  supertype; 

type  ship  optional  supertvpe  of 

<  oiltanker; 
cruiseship 

> 

The  word  optional  indicates  that  a  ship  may  be  either  an  oiltanker  or  a  cruiseship  (although  not  both), 
but  may  be  neither.^ 

Although  the  verbal  names  used  for  types  often  give  no  clue  to  supertype  connections,  as  vvith  the 
names  "ship"  and  "oiltanker",  certain  patterns  should  be  considered.  Noun  pairs,  such  as  "cruise 
ship",  are  frequently  used  to  name  subtypes  of  the  second  noun,  as  are  compound  nouns.  Adjectives 
frequently  are  used  with  nouns  in  the  same  way,  as  in  "military  vessel". 

In  order  to  fully  describe  a  process,  it  is  sometimes  necessary  to  refer  to  individual  objects  (values) 
as  well  as  to  entire  classes.  The  names  of  individuals  may  be  freely  chosen  by  the  specifier,  but  the 
type  to  which  each  belongs  must  be  declared.  This  can  be  done  as  part  of  the  type  declaration; 

type  port  includes  {SanlaBarbara,  Seattle}-, 

type  grain  definition  {Corn,  Wheat); 

type  fuel  definition  {Oil,  NaturalGas) 

The  declaration  can  either  enumerate  some  of  the  instances  of  the  types  (includes)  or  may 
enumerate  them  all  (definition). 

Linguistic  clues  that  indicate  the  need  for  declaring  individual  instances  of  types  include  the  use  of 
proper  nouns,  mass  nouns,  and  collections  of  adjectives  (like  color  names)  used  to  modify  the  same 
type  names. 

The  primary  motive  for  declaring  various  types  of  objects  in  a  specification  is  that  the  instances  of  a 
type  are  perceived  to  share  characteristics  not  common  to  instances  of  other  types.  These  include: 


2 


Gist  also  permits  declarations  of  "overlapping”  aubtypes,  and  types  with  multiple  supertypes. 
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*  relationships  that  hold  between  the  objects 

*  actions  that  may  be  performed  on  the  objects 

*  constraints  on  the  objects 

The  remainder  of  the  declaration  portion  of  Gist  is  concerned  with  specifying  these  regularities. 

2.3  RELATIONS  AND  ATTRIBUTES 

In  describing  a  process  in  English,  we  use  specific  words  and  syntax  to  describe  the  ways  objects 
are  related  to  one  another.  In  "ship  bound  for  SantaBarbara"  the  phrase  "bound  for"  indicates  a 
particular  relation  that  can  hold  between  ships  and  ports-namely,  a  ship  can  be  scheduled  to  go  to  a 
particular  port.  "A  ship  based  in  SantaBarbara"  uses  a  different  phrase,  "based  in"  to  talk  about  a 
different  relation  between  the  same  two  types.  "A  ship  containing  50  tons  of  wheat"  indicates  yet 
another  relation  in  this  domain-  ships  may  contain  specific  quantities  of  specific  cargos. 

In  Gist,  these  various  kinds  of  associations  that  may  relate  the  individual  instances  of  the  types  are 
called  relations.  A  relation  is  declared  by  giving  it  a  name  and  by  naming  the  object  types  it  relates: 

relation  CONTAINS  (ship,  cargo,  tonnage)  (2.1) 

This  does  not  specify  which  instances  of  ship,  cargo,  and  volume  are  related  or  when  such 
relationships  arise.  But  it  does  say  that  the  relation  name  CONTAINS  will  not  be  used  to  relate 
objects  of  any  types  other  than  the  three  named. 

If  in  a  given  state  the  ship  USS-Prairie  contained  50  tons  of  Wheat,  we  would  say  in  Gist 
terminology,  that  there  was  a  relationship  in  CONTAINS  having  USS-Prairie  filling  the  ship  role, 
Wheat  filling  the  cargo  role,  and  50  filling  the  tonnage  role. 

Technically,  each  role  of  a  relation  has  both  a  name  and  a  type.  In  many  cases,  the  specifier  will 
feel  comfortable  using  the  same  name  for  the  role  as  was  used  for  its  type.  This  is  done  by  using  only 
the  type  name  in  the  declaration,  as  in  (2.1)  above.  In  other  cases,  there  is  mnemonic  value  in 
choosing  a  name  for  the  role  that  is  more  expressive  than  the  type  name.  Finally,  there  are  constructs 
in  Gist  that  use  the  role  name  explicitly.  For  relations  that  have  more  than  one  role  of  the  same  type, 
these  constructs  are  useable  only  if  those  roles  have  been  given  distinct  names.  Since  it  is  a  bad  idea 
to  try  to  anticipate  which  roles  one  may  need  to  reference  by  name  in  a  specification,  one  should 
always  choose  distinct  names  for  two  roles  of  the  same  type  in  the  same  relation. 

There  are  two  ways  to  indicate  a  name  for  a  role  of  a  relation  when  it  is  to  differ  from  the  type  name. 
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One  is  to  choose  as  the  role  name  a  composite  name  of  the  form  ''typename.distinguisher'*-e.g., 
"couNTRY.FROM”.  In  this  case,  the  composite  name  is  the  role  name  while  its  prefix  (in  this  case, 
"country")  is  the  role  type.  Alternatively,  one  can  choose  an  arbitrary  name  for  the  role  and  specify 
its  type  explicitly,  separating  the  two  names  by  a  "I”  in  the  declaration.  Suppose  we  wanted  to  have  a 
relation  that  indicated  what  goods  were  being  traded  among  nations.  We  could  do  this  with  a  relation 
declared  by: 

relation  TRADE  (country.from,  GOODS  |  cargo,  Country.to) 
making  TRADE  a  ternary  relation  having  roles  named  country.from,  goods,  and  country.to, 
whose  types  are  country,  cargo,  and  country,  respectively. 

In  general,  one  can  imagine  countless  relationships  in  any  moderately  rich  process  domain.  It  is 
not  possible  to  determine  in  advance  precisely  which  ones  will  be  sufficient,  or  convenient,  to  use  for 
the  entire  specification.  A  good  rule  of  thumb,  however,  is  to  start  with  those  mentioned  in  the  verbal 
process  description.  Linguistic  clues  to  relationships  include: 

•  the  use  of  ''situational"  verbs  like  "contain"  or  "own", 

•  the  use  of  passive  forms  like  "be  connected  to"  or  "be  bound  for", 

•  noun  phrases  modified  by  prepositional  phrases,  like  "the  berth  of  a  ship"  or  "the  salary 
of  an  officer", 

•  possessive  forms,  like  "the  ship's  country  of  registry",  or  "the  officer's  salary". 

2.3.1  Attributes 

It  is  usually  the  case  that  a  large  percentage  of  the  useful  relations  in  a  specification  will  be  binary 
relations.  These  can  be  declared  and  used  like  ordinary  N-ary  relations,  but  may  also  be  declared  and 
used  in  a  special  attribute  notation  in  Gist.  The  use  of  attribute  notation  makes  the  declaration  of  the 
relationship,  its  use,  and  the  specification  of  constraints  on  it  more  concise  and,  arguably,  easier  to 
understand. 

Attributes  are  declared  as  part  of  type  declarations.  For  example,  to  declare  the  binary  relationship 
between  ships  and  their  country  of  registry,  the  attribute  is  named  in  the  declaration  of  one  of  the 
types; 

type  ship  (registry  |  country); 

This  declaration  indicates  that  ships  and  countries  are  related  by  an  attribute  named  registry. 
Elsewhere  in  Gist.  ":  registry"  is  used  to  designate  the  mapping  for  ships  to  countries,  and 
REGISTRY"  to  designate  the  inverse  mapping  from  countries  to  ships. 
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Many  attributes  may  be  declared  in  a  single  type  declaration.  The  declaration: 

type  ship  (registry  |  count  ry,  capacity  ]  tonnage,  deadweight  |  tonnage)  (2.2) 

specifies  the  existence  of  three  mappings,  whose  names  are  intended  to  convey  the  meaning  of  the 
mappings. 

The  declaration  of  relationships,  including  attributes,  should  be  mude  for  the  most  general 
applicable  types.  It  is  then  "inherited"  by  the  subtypes  of  those  types.  For  example,  having  declared 
the  attribute  "registry"  between  ships  and  countries,  there  is  no  need  to  duplicate  the  declaration 
for  subtypes  of  ship,  such  as  oiltanker,  or  for  subtypes  of  country. 


Having  decided  to  use  an  attribute  declaration  as  opposed  to  a  binary  relation,  a  specifier  still  must 
decide  in  which  of  the  two  relevant  type  decl»'ations  to  include  the  declaration  of  the  attribute.^'  *  It 
is  impossible  to  do  more  than  give  guidelines  on  this  matter,  since  there  is  no  formal  distinction  in  the 
declaration  content.  As  is  frequently  the  case  with  guidelines  they  may  suggest  conflicting 
organizations. 

•  Linguistic  guideline.  Choose  an  attribute  name  that  makes  the  phrase; 

<attribute  name>  of/f'n/for/ <type>^  must  be  <type>2  . 

sound  like  a  sensible  description  of  the  relationship.  Declare  the  attribute  within  the 
declaration  of  type., .  Each  attribute  in  (2.2)  above  would  be  suggested  by  this  rule,  since: 

registry  of  ship  must  be  country 
capacity  of  ship  must  be  tonnage 
deadweight  of  ship  must  be  tonnage 

sound  right. 

•  Functionality  guideline.  If  the  mapping  is  many  to-one  -each  object  of  type,  maps  to 
exactly  one  object  of  typCj,  but  an  object  of  typOg  may  map  to  zero,  one,  or  more  objects 
of  type,”then  declare  the  attribute  with  the  declaration  of  type,.  All  three  attributes  in 
(2.2)  suggest  this.® 

•  Structural  guideline.  Some  relationships  have  a  "part-whole"  feeling  to  the  specifier. 
Sometimes  this  has  a  strong  physical  basis  in  the  real  world,  as  with  the  slips  of  a  pier. 

Other  times  the  feeling  is  more  one  of  a  logical  dependency  specific  to  the  process  under 
consideration,  as  with  the  dependents  of  an  employee.  Try  to  declare  such  attributes  as 
part  of  the  declaration  of  the  "whole"  type. 


®I1  could  be  redur>darttly  stated  in  both  places,  but  this  would  not  be  a  good  idea  in  general,  since  any  change  to  the 
deciaration  would  require  two  changes  in  the  specification  to  maintain  consistency. 

*Of  course,  if  the  two  types  are  the  same,  there  is  no  problem. 

^Certain  default  constraints  on  the  mappings,  described  later,  are  designed  to  mesh  well  with  this  guideline. 
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It  is  possible,  by  means  described  in  Section  2.4,  to  specify  constraints  on  attribute  mappings  alone 
with  the  attribute  declaration  itself.  -Sometimes  the  restriction  of  the  mapping  that  involves  a  named 
subtype  of  one  of  the  two  types  is  more  highly  constrained  than  the  mapping  as  a  whole.  For 
instance,  crewmember’s  salaries  may  range  from  $10,000  to  $40,000,  but  officer's  salaries  may  have 
to  be  above  $25,000.  When  this  situation  arises,  more  effective  use  can  be  made  of  Gist’s  constructs 
if  the  attribute  is  declared  with  the  type  whose  subtype  is  further  constrained-crewmember,  in  this 
example. 

'2.3.2  Attributes  and  Subtypes 

Whenever  a  proposed  attribute  relationship  involves  a  type  whose  instances  are  totally  enumerated 
by  literals  in  the  specification,  the  specifier  should  consider  the  possibility  that  a  more  natural  and 
useful  specification  could  be  obtained  by  using  the  supertype  concept.  In  other  words,  the  attribute 
relationship  between  type^  and  enumerated  typeg  can  be  replaced  by  having  a  named  subtype  of 
type^  for  each  instance  of  typeg,  and  eliminating  typeg  entirely.  A  particularly  common  situation  to  be 
aivare  of  is  the  use  of  "flag"  types  whose  instances  are  "yes”  and  "no",  or  "true”  and  "false",  or  0 
and  1 .  It  is  almost  aiv,fays  preferable  to  provide  a  name  for  each  case  and  make  the  encompassing 
type  a  "unique  supertvoe  flf"  these  named  types,  or  to  name  one  of  the  cases  (typically,  the 
"positive"  one)  and  make  the  encompassing  type  an  "optional  supertvoe  gf "  that  named  type. 

For  example,  it  would  be  preferable  to  specify  the  fact  that  some  ships  are  government  owr  ed  as: 

type  shipf  ...)  optional  supertvoe  of 
<governmentship  (...)>; 

rather  than; 

type  ship(...,GOVERNMENTOWNED  |  {yes,No)) 

2.4  CONSTRAINTS 

The  declaration  of  types  and  relationships  lays  out  a  wide  variety  of  possible  process  states-  that  is, 
states  containing  collections  of  instances  of  those  types  and  relationships  between  objects  of 
appropriate  types.  However,  it  is  nearly  always  obvious  that  many  of  these  states  may  never  really 
arise  Sometimes  this  is  because  of  physical  constraints  in  the  process  domain-e.g.,  a  ship  cannot 
simultaneously  occupy  multiple  slips,  nor  can  multiple  ships  simultaneously  occupy  one  slip.  In  other 
cases,  it  is  not  physical  reality,  but  the  desired  process  which  restricts  the  potential  states.  For 
example,  there  may  be  a  "rule"  which  states  that  no  ship  should  simultaneously  carry  fuel  and  grain. 
In  either  case.  Gist  provides  declarations  for  specifying  such  constraints  on  possible  states. 
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The  most  general  construct  permits  the  specifier  to  state  that  a  given  condition  must  either: 

•  hold  in  every  process  state  (a  requirement) 

•  hold  in  no  process  state  (a  prohibition). 

The  constraining  condition  is  specified  by  a  Gist  predicate.  Predicates  are  discussed  in  more  detail  in 

Section  2.7,  but  basically  follovr  conventional  predicate  calculus  notation.  For  example, 

always  prohibited  3  ship, fuel, grain  ||  CONTAINS(sb/p,  fuel,  $)  A 

CONTAINS(s/>/p,  grain,  $) 

would  state  that  no  ship  may  ever  be  used  to  simultaneously  transport  fuel  and  grain. 

always  required  V  oUtanker  ||  3  officer  ||  officer  :  assignment  =  oiltanker  A 

officer :  seniority  >  10 

would  require  that  officer  assignments  ensure  that  every  oiltanker  have  at  least  one  officer  with  over 
to  years  experience. 

Although  it  is  possible  to  describe  all  Gist's  constraints  in  this  way.  experience  shows  that  many 
constraints  can  be  naturally  expressed  as  constraints  "on"  particular  relations  or  types.  For  such 
constraints  Gist  provides  a  means  of  expressing  the  constraint  as  part  of  the  type  or  relation 
declaration. 

With  respect  to  a  given  relation,  there  are  two  classes  of  constraints  which  may  be  specified.  The 
first  concerns  constraints  on  individual  relationships  in  the  relation.  For  instance,  to  prohibit  trade  of 
any  product  between  two  countries  which  are  both  producers  of  that  product,  one  could  place  a 
constraint  on  the  TRADE  relation  in  terms  of  a  PRODUCES  relation: 

relation  PRODUCES  (Country,  goods  ( cargo); 
relation  TRADE  (country. FROM,  GOODS  |  cargo,  country  .to) 
where  always  prohibit  PRODUCES(counfry.from,  goods)  A 
PRODUCES(counfry.to.  goods) 

SM 

The  second  form  of  relation-specific  constraint  restricts  the  collection  of  relationships  which  may 
co-exist  in  a  given  relation.  For  any  partitioning  of  the  roles  of  a  relation  into  two  non-empty 
partitions,  one  may  view  the  relation  as  a  mapping  from  one  partition  to  the  other.  It  is  possible  to 
constrain  the  "multiplicity"  of  such  a  mapping.  For  example,  the  relation  CONTAINS  implicitly 
provides  a  mapping  from  ship-cargo  pairs  to  tonnages.  For  a  given  ship-cargo  pair,  there  can  be  at 
most  one  tonnage  (the  amount  of  that  cargo  or  that  ship).  But  for  a  given  tonnage,  there  is  no 
restriction  on  the  number  of  ship-cargo  pairs  which  CONTAINS  relates  to  it.  This  can  be  expressed 
by  augmenting  the  declaration  of  CONTAINS: 
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relation  CONTAINS  (ship,  cargo,  tonnage) 
any  (ship,  cargo)  optional 

The  pair  (ship, cargo)  defines  the  role  partitioning.  The  other  partition  is  implicitly  (tonnage).  The 
word  any  preceding  the  explicit  partition  indicates  no  constraint  on  the  mapping  from  (tonnage)  to 
(ship, CARGO).  The  word  optional  indicates  that  a  given  (ship, cargo)  pair  may  map  to  zero  or  one 
(tonnage).  This  constraint  could  also  have  been  written 
optional  (tonnage)  any 

The  ways  to  specify  the  multiplicity  of  a  mapping  include: 
indicator  multiplicity 

any  no  restriction 

optional  0  or  1 

unicue  exactly  1 

multiple  1  or  more 

any  integer  N  exactly  N 

When  attributes  are  used  to  specify  binary  relationships,  it  is  still  possible  to  state  both  forms  of 
constraint  w'ithin  the  type  declaration  which  introduces  the  attribute.  The  "mapping  multiplicity" 
constraints  are  indicated  by  placing  multiplicity  indicators  before  and  after  the  attribute  specification. 
For  example: 

type  ship  (unloue  registry  [  country  any. ...)  (2.3) 

constrains  the  relationship  between  ships  and  their  country  of  registry  so  that  each  ship  must  have 
exactly  one  country  of  registry,  but  a  given  country  may  have  zero  or  more  ships  registered  in  it. 

If  no  multiplicity  indicator  is  given  in  a  declaration  the  default  is  ''unioue”  for  the  mapping  from 
declaration  type  to  attribute  type,  and  "any"  for  attribute  type  to  declaration  type.  Thus  example  (2.3) 
could  be  v/ritten  simply  as: 

type  ship  (registry  |  country,  ...) 
defaulting  both  multiplicity  constraints. 

Constraints  on  individual  relationships  in  an  attribute  relation  can  also  be  declared  within  the  type 

declaration  in  which  the  attribute  is  declared.  In  fact,  it  is  possible  to  constrain  combinations  of 

different  attributes  of  a  given  type,  as  illustrated  in  the  following  examples: 

type  draft  definition  natnum 
type  port  (maxdraft  |  draft,  country  multiple) 
type  ship  (...,  ORAFT.SHiP,anyPORTOFCALL|  port,  PORT.HOME) 
where  always  prohibit  drait.ship  >  portofcall :  maxdraft 
end 

would  prohibit  a  ship  from  having  a  port  of  call  for  which  the  ship  was  too  large. 


(2.4) 
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In  addition,  one  could  require  that  a  ship  be  capable  of  entering  its  home  port  by  including  in  the 
ship  declaration 

always  require  draft. ship  <  port. home  :  maxdraft 

A  type  constraint  of  the  form  “always  prohibit  condition"  declares  that  the  coridition  may  never  hold 
for  any  instance  of  the  type  in  whose  declaration  the  constraint  appears.  The  condition  refers  to  the 
object  being  constrained  by  using  the  type  name  as  a  variable.  It  may  also  refer  to  the  objects  in 
attribute  relationships  with  that  object  by  the  attribute  names  used  in  the  declaration.  The  condition 
holds,  and  thus  violates  the  constraint,  if  any  combination  of  attribute  values  satisfy  it.  Thus 
constraint  ((2.4))  prohibits  a  ship  from  having  any  port  of  call  which  is  inappropriate  regardless  of  how 
many  acceptable  ports  of  call  it  may  have  at  the  same  time. 

Analogously,  an  "always  require  condition"  constraint  on  a  type  requires  the  condition  to  hold  for 
every  instance  of  the  type,  for  aM  combinations  of  attribute  values.  In  all  cEises,  "always  require 
condition"  and  "always  prohibit  Icondition"  are  equivalent.  As  with  other  predicates,  it  is  generally 
easier  to  read  a  constraint  in  a  form  which  reduces  the  use  of  the  logical  operator  1. 


2.4.1  Use  of  Constraints 

There  are  two  primary  purposes  for  constraints  in  Gist  specifications.  The  first  is  as  an  aid  to 
someone  trying  to  understand  or  implement  a  (portion  of)  a  specification.  Understanding  and 
implementation  both  involve  a  great  deal  of  mental  simulation  of  behavior.  This  in  turn  requires 
consideration  of  how  behavior  will  proceed  under  various  conditions.  Constraints  are  a  powerful 
means  of  limiting  the  range  of  conditions  which  must  be  considered. 


The  second  use  of  constraints  is  to  aid  the  specification  writer.  Consider  two  ways  people  use  what 
we  might  term  "constraints"  in  English-e.g,  "Don’t  let  your  bank  balance  be  negative." 

«  This  might  be  treated  as  a  rule  to  do  something  (although  what  to  do  is  not  stated) 
whenever  the  balance  drops  below  0  to  rectify  the  situation.  In  programming  terms,  use 
of  a  constraint  does  ngl  say  that  the  condition  always  holds,  but  that  when  it  doesn’t  hold, 
some  form  of  "interrupt"  process  is  used  to  re-establish  it.  Gist’s  semantics  does  ngl 
treat  constraints  in  this  way. 

•  Another  use  people  make  of  constraints  is  to  limit  choices.  The  bank  balance  constraint 
will  limit  a  person  s  selection  when  buying  a  stereo,  for  example.  This  is  Gist’s  semantics 
for  constraints- -that  choices  are  always  to  be  made  so  that  no  constraint  will  ever  be 
violated.  This  implies  that  choices  are  limited  not  only  by  their  immediate  affects,  but  by 
their  "downstream"  consequences  as  well.  This  is  analogous  to  a  person  realizing  that 
he  can’t  buy  a  stereo,  not  because  his  bank  balance  would  go  negative  when  he  brought 
it,  but  because  it  would  go  negative  when  he  paid  the  rent  two  days  later  (a  behavior  for 
which  he  has  no  alternative). 


V 
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It  is  often  easier  to  specify  behavior  by  allowing  the  procedural  part  of  the  specification  to  contain  too 
many  behaviors  and  letting  constraints  prune  the  alternatives. 

In  choosing  what  constraints  are  worth  stating  explicitly,  a  verbal  process  description  is  of  limited 
use.  Some  constraints  may  be  expressed  verbally,  but  many  are  such  "common  knowledge"  that 
they  are  left  unstated  - "two  ships  can’t  be  in  the  same  slip",  "a  ship  may  not  be  loaded  above  its 
capacity".  A  specifier  can  state  any  obvious  constraints  which  come  to  mind  before  working  on  the 
procedural  portion  of  his  specification.  But  he  should  be  on  the  lookout  for  situations  where  he  is 
writing  procedural  specification  for  the  purpose  of  "avoiding"  a  problem.  An  example  of  the  way 
constraints  can  collaborate  to  simplify  the  procedural  part  of  a  specification  is  presented  in  section 
2.8. 

2.5  DERIVATION  RULES 

Derivation  rules  are  provided  in  Gist  to  permit  the  specifier  to  expand  his  vocabulary  to  include 
concepts  which  can  be  defined  in  terms  of  other  concepts,  without  having  to  treat  the  concepts  as 
though  they  were  independent  and  maintain  their  equivalence  procedurally.  We  might  say  "a  ship  is 
docked  at  a  pier  if  and  only  if  it  is  berthed  in  some  slip  of  that  pier"  to  define  the  concept  of  "docked 
at"  in  terms  of  "berthed  in"  and  the  relationship  between  slips  and  piers. 

Gist  permits  derivation  rules  for  types  and  relations  (including  attribute  relations).  To  define  a  new 
derived  relation,  the  Gist  specification  should  include  a  normal  declaration  of  the  relation,  together 
with  a  predicate  stating  the  conditions  under  which  the  relation  holds: 

relation  TRADE-PARTNERS  (COUNTRY. i,  COUNTBY.2) 
definition  TRADE  {country.  1,  S.  country. 2)  A 
TRADE  {country. 2,  %.  country. 1) 

would  define  a  binary  relation  TRADE- PARTNERS  which  would  hold  betv/een  two  countries  if  and 
only  if  countries  had  mutual  TRADE  relationships  (regardless  of  the  goods  involved). 

Derived  concepts  in  Gist  may  be  used  in  all  ways  like  non-derived  concepts  (including  their  use  in 
the  deriveration  of  other  concepts)  save  one:  the  derived  relation  mav  not  be  used  as  a  primitive  state 
change  statement  (see  section  2.8.1). 

A  derived  attribute  is  specified  by  including  a  normal  declaration  for  it  and  a  derivation  for  it  as  well. 

type  ship  (...,  optional  berth  1  slip  optional. 

optional  dock  |  pier  derivation  ship  :  berth' :  atpier 

This  defines  the  "dock"  attribute  to  relate  a  ship  to  a  pier  if  and  only  if  the  ship  is  in  a  slip  at  that  pier. 
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Finally,  one  can  give  a  definition  for  a  type  name,  where  the  definition  is  a  predicate,  written  in 
terms  of  the  type  name,  which,  if  satisfied  by  some  object,  qualifies  that  object  as  an  instance  of  the 
type. 

type  port  (. . .)  optional  supertvoe  gf 

<oilport  definition  3  pier  ||  pier :  port  *  oilport  A 

pier :  handles  >  Oil 

> 

Under  this  declaration,  a  port  is  an  oilport  if  and  only  if  it  has  a  pier  which  handles  oil.^ 

2.6  OBJECT  EXPRESSIONS 

The  object  expression  is  Gist's  means  of  referring  to  particular  objects,  or  values,  within  predicates 
and  statements.  The  referent(s)  of  an  object  expression  is  determined  by  the  process  state  in  which 
the  expression  is  evaluated  and  the  referents  of  any  variables  used  freely  within  the  expression.  An 
object  expression  may  refer  to  a  single  object,  in  which  case  it  is  said  to  make  a  deterministic 
reference.  It  may  refer  to  multiple  objects,  in  which  case  it  is  said  to  make  an  ambiguous  reference.  It 
is  also  possible  for  an  object  expression  to  have  no  referent  at  all,  in  which  case  it  is  said  to  make  an 
anomalous  reference. 

2.6.1  Literals 

The  simplest  object  expression  in  Gist  is  a  literal.  Distinct  literals  refer  to  distinct  objects,  and  all 
occurrences  of  a  given  literal  refer  to  the  same  object.  Both  numeric  literals  (5000)  and  non-numeric 
literals  (Corn)  are  allowed.  Non-numeric  literals  must  consist  of  single  identifiers,  and  those 
identifiers  should  not  be  used  as  the  names  of  relations,  actions,  types,  or  variables  elsewhere  in  a 
specification. 

2.6.2  Variables 

Variable  names  in  Gist  are  arbitrary  identifiers.  Each  variable  name  has  a  type  which  restricts  the 
potential  referents  of  the  variable.  The  type  may  be  implicit  in  the  variable’s  name,  or  may  be  declared 
explicitly.  To  have  an  implicitly  typed  variable,  it  is  only  necessary  to  choose  its  name  in  the  same  way 
as  names  are  chosen  for  implicitly  typed  attributes-  e.g.,  "port. old"  could  be  used  as  the  name  for  a 
variable  with  implicit  type  "port".  Variables  obtain  their  referents  in  two  ways: 


type  which  is  declared  to  be  a  unique  supertype  of  some  collection  of  types  rnay  not  also  have  a  definition;  the  unique 
superlvoe  gf  in  fact  constitutes  a  definition  of  the  supertype. 
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•  A  variable  can  be  used  as  a  formal  parameter  of  an  action.  It  then  obtains  a  referent 
object  from  an  actual  parameter  in  an  invocation  of  the  action,  and  can  be  used  to  refer 
to  that  object  within  the  action's  defining  statement. 

*  Quantified  variables  can  be  used  in  predicates  as  they  are  in  predicate  calculus.  These 
variables  obtain  as  referents  objects  which  satisfy  the  predicate.  In  many  uses  of 
predicates,  these  variable  names  can  then  be  used  later  to  refer  to  those  objects. 

2.6.3  Attribute  Reference 

Through  the  use  of  attribute  names  it  is  possible  to  refer  to  the  objects  related  to  a  given  object  in 
an  attribute  relationship.  Such  an  expression  may  be  an  anomalous,  deterministic,  or  non- 
deterministic  reference. 

ship.  7  :  CAPACITY 

would  refer  to  the  tonnage  which  is  the  capacity  of-  the  ship  referred  to  by  the  variable  "ship.!". 

attribute"  maps  objects  of  the  type  in  which  the  attribute  was  declared  (in  this  case,  "ship")  to 
objects  of  the  type  specified  for  the  attribute  (in  this  case,  "tonnage"). 

USA  ::  REGISTRY 

would  refer  to  any  ship  whose  country  of  registry  was  the  USA.  attribute"  performs  the  inverse 
mapping  frorn  attribute". 

2.6.4  Descriptive  Reference 

A  descriptive  reference  is  a  reference  to  an  object  obtained  by  specifying  its  type  and,  optionally,  a 
predicate  which  must  be  true  of  it.  Any  object  of  the  indicated  type  for  which  the  predicate  holds  is 
then  a  referent  of  the  expression.  The  expression 
S  c  I  country  ||  TRADE(c,0/7,US4) 

would  have  as  its  referent  any  country  which  traded  oil  to  the  USA.  In  this  expression,  c  \  country 
indicates  that  the  type  of  object  being  referred  to  is  "country",  while  "c"  is  an  identifier  used  to  refer 
to  the  desired  object  in  the  predicate  which  follows  the  symbol  "H".  This  expression  could  also  be 
written  as: 

a  country  ||  JRADE{counlry,Oil,USA) 

An  expression  which  refers  to  any  instance  of  a  type  is  written  by  omitting  the  predicate: 


a  country 
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2.6.5  Arithmetic  Expressions 

Expressions  whose  referents  are  arithmetic  values  may  be  combined  using  the  arithmetic  operators 
+ ,  •,  *,  and  \  to  compute  other  arithmetic  values,  as  is  done  in  algebraic  programming  languages. 
Furthermore,  the  monadic  operator  "count"  may  be  applied  to  any  expression  to  obtain  the  number 
of  referents  which  that  expression  has.  For  instance, 

CQunttSeaf.;;  ::  port  .home) 

is  an  arithmetic  expression  whose  value  is  the  number  of  ships  having  Seattle  as  their  home  port.  If 
the  operand  of  "count"  is  anomalous,  then  the  value  of  the  "count"  expression  is  zero.^ 

Parentheses  may  be  used  to  enclose  subexpressions  both  for  readability  and  to  override  the  default 
groupings  imposed  by  Gist’s  syntax. 

2,7  PREDICATES 

A  predicate  is  the  means  by  which  conditionality  is  introduced  into  a  specification.  There  are  a 
number  of  basic  pieces  of  information  in  a  process  state  which  can  be  used  as  the  basis  of  tests: 

•  the  existence  of  objects 

•  the  classification  of  objects  by  type 

•  the  relationships  between  objects 

Like  predicate  calculus,  Gist  permits  the  expression  of  complex  predicates  through  the  use  of 
quantified  variables  and  logical  combinations  of  predicates  involving  those  variables  and  literals. 

Semantically,  a  predicate  may  be  said  to  be  either  TRUE  or  FALSE  relative  to  a  particular  process 
state  and  particular  assignment  of  referents  to  its  variables.  In  the  following  descriptions,  where  no 
confusion  will  arise,  we  will  simply  refer  to  predicates  as  TRUE  or  FALSE. 

2.7.1  Propositions 

All  predicates  are  built  up  from  propositions.  One  form  of  proposition  is  a  test  for  the  existence  of 
an  object.  Since  objects  may  be  created  and  later  destroyed  (see  section  2.8.1)  it  is  possible  to  have 
an  expression  (e  g.,  a  variable)  whose  referent  is  an  object  which  has  been  destroyed.  The  monadic 
predicate  "extant"  is  used  to  test  for  the  existence  of  the  referent  of  an  expression. 


^Although  using  "count"  to  test  whether  the  number  of  referents  of  an  expression  is  lero  does  in  effect  test  whether  it  is 
anomalous,  the  predicate  "extant"  (see  section  2.7)  is  the  stylistically  preferred  way  of  doing  this. 


PREDICATES 


2-15 


extant  ship.  l 

is  a  proposition  which  is  TRUE  if  and  only  if  the  referent  of  the  variable  "ship.!’'  exists  in  the  state  in 
which  the  proposition  is  evaluated.  Since  a  proposition  using  "extant"  is  FALSE  if  the  operand  of 
"extant"  is  anomalous,  it  is  also  useful  for  testing  whether  an  expression  has  any  referents. 

AnoLier  basic  proposition  is  a  test  for  referential  identity  of  two  expressions.  Any  two  object 
expressions  may  be  compared  with  the  logical  operator "  =  ".  The  proposition  is  TRUE  if  and  only  if 
the  two  expressions  have  at  least  one  referent  in  common.  If  either  or  both  expressions  is  anomalous, 
or  they  have  disjoint  sets  of  referents,  the  proposition  is  FALSE. 
ship.1  :  PORTOFCALL  =  Ship.2  :  PORT.HOME 

would  be  TRUE  if  the  referent  of  "ship  l"  had  the  home  port  of  the  referent  of  "ship.2"  as  one  of  its 
ports  of  call. 

It  is  also  possible  to  test  for  non-identity  of  two  expressions,  using  the  logical  operator  The 
proposition  is  TRUE  if  the  two  object  expressions  have  non  empty  sets  of  referents  which  are  not 
identical.  If  either  or  both  expressions  is  anomalous,  the  proposition  is  FALSE. 
ship,  t  :  PORTOFCALL  *  Ship.2  :  PORT.HOME 

would  be  true  if  the  referent  of  "ship.  l "  had  any  porl  of  call  other  than  the  home  port  of  the  referent  of 
"ship.2." 

Another  form  of  proposition  is  a  test  for  the  classification  of  an  object. 

Seattle  ::  port.home  isa  oiltanker 

would  be  true  if  any  ship  having  Seattle  as  home  port  was  classified  as  an  oiltanker. 

Arithmetic  expressions  may  be  compared  using  the  comparison  operators  <.  <,  >,  >,  and,  of 
course,  the  identity  comparison  =  . 

The  final  form  of  proposition  introduced  in  this  section  is  a  test  for  the  existence  of  a  named 
relationship  between  objects.  The  relation  must  be  specified  by  name,  and  the  objects  being  tested 
are  specified  by  object  expressions.  A  relationship  is  TRUE  if  any  combination  of  referents  of  the 
object  expressions  fill  the  corresponding  roles  of  any  relationship  in  the  named  relation.  If  the  named 
relation  is  n-ary.  exactly  n  object  expressions  must  appear  in  the  relationship  test.  The 
correspondence  between  the  object  expressions  in  the  proposition  and  the  roles  of  the  relation  is 
positional. 

CONTAINS(Sea/f/e  PORT.HOME,  a  grain,  a  tonnage  ||  tonnage  >  5000)  (2.5) 

is  a  proposition  which  is  true  if  there  is  any  relationship  in  CONTAINS  involving  a  ship  whose  home 


L 
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port  is  Seattle,  a  cargo  which  is  an  instance  of  “grain",  and  a  tonnage  which  is  greater  than  5000. 
Note  the  positional  correspondence  between  the  three  object  expressions  in  ((2.5))  and  the  roles  in 
the  declaration  of  CONTAINS  in  example  ((2.1)). 

An  abbreviation  which  is  frequently  useful  in  propositions,  and  particularly  in  relationship  tests,  is 
the  use  of  the  symbol  ”$"  as  an  object  expression.  It  may  be  thought  of  as  having  all  existing  objects 
as  its  referents,  and  thus  serves  as  a  test  of  whether  any  existing  object  satisfies  the  predicate  in 
which  it  is  used.  For  instance, 

CONTAINS(5eart/e  ;;  port.home,  a  grain,  $) 

is  a  proposition  whiph  is  TRUE  if  any  ship  having  Seattle  as  its  home  port  contains  any  amount  of  a 
cargo  which  is  an  instance  of  "grain".  It  should  be  noted  that,  for  each  of  the  propositional  forms,  the 
proposition  is  TRUE  if  any  referent(s)  of  the  expression(s)  used  as  operands  have  the  property  being 
tested,  or  bear  the  tested  relation  to  one  another.  In  all  cases,  the  propositions  have  the  semantics 
normally  associated  with  them  in  programming  languages  when  all  expressions  involved  are 
deterministic. 

2.7.2  Quantified  Predicates 

Predicates  may  make  use  of  existentially  and  universally  quantified  typed  variables.  These 
variables  appear  freely  within  the  scope  of  the  quantifier.  A  predicate  O  of  the  form: 

3Mt,,...vJtJlP 

is  TRUE  if  and  only  if  there  exist  objects  0.|, ...  O^.  where  O.  is  an  instance  of  t^,  such  that  P  is  TRUE 
when  free  occurrences  of  v.  in  P  are  taken  to  refer  to  O^.  Furthermore,  0  is  said  to  be  TRUE  subject  to 
the  assignment  of  0|  to  v.^.  Otherwise,  O  is  FALSE.  For  example. 

3  c  I  cruiseship  ||  c  :  registry  =  USA  (2.6) 

would  be  TRUE  if  any  instances  of  "cruiseship"  had  USA  as  their  country  of  registry. 

Analogously,  a  predicate  0  of  the  form: 

Vv,|t,,...vJtJ|P 

is  FALSE  if  and  only  if  there  exist  objects  0.|, ...  0^^,  where  is  an  instance  of  t^,  such  that  P  is  FALSE 
when  free  occurrences  of  v.  in  P  are  taken  to  refer  to  O^.  Furthermore.  Q  is  said  to  be  FALSE  subject 
to  the  assignment  of  to  v..  Otherwise,  O  is  TRUE.  For  example, 

V  0  I  oiltanker  ||  o  :  portofcall  :  country  »  USA 
would  be  TRUE  if  every  instance  of  "oiltanker"  had  some  port  of  call  in  the  USA.  (It  would  also  be 
TRUE,  by  definition,  if  there  were  no  instances  of  the  type  "oiltanker".) 
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Quantified  variables  may,  like  role  names,  be  named  so  that  the  variables  type  is  implicit  in  its  name. 
Example  ((2.6))  could  be  written  as: 

3  cruiseship  ||  cruissship  :  registry  »  USA 

2.7.3  Predicate  Composition 

Predicates  may  be  combined  with  the  unary  prefix  1  and  the  boolean  infix  operators  A,  V, 
®  (exclusive  or),  =»  (implies),  and  =  (equivalent)  to  form  logical  compounds.  The  precedence  for 
parsing  logical  compounds  is  the  standard  precedence  of  propositional  logic.  Parentheses  may  be 
used  for  legibility  and  for  groupings  other  than  that  given  by  the  default  precedence.  The  semantics 
of  logical  compounds  is  defined  by  the  standard  truth  tables. 

2.8  ACTION  DECLARATIONS 

Any  application  dorr.ain  will  have  a  variety  of  activities  carried  out  by  processes  in  that  domain. 
These  activities  change  the  state  of  the  process  in  some  way.  They  may  create  or  destroy  domain 
objects  (launching  or  decomissioning  a  ship),  change  object  relationships  (giving  a  ship  an  additional 
port  of  call),  or  classify  or  declassify  objects  (making  a  crewmember  an  officer).  Furthermore,  the 
execution  of  an  action  serves  to  "mark  time"  in  the  process,  in  the  sense  that  Gist’s  facility  for 
temporal  reference  permits  reference  to  past  execution  states  in  terms  of  the  start,  completion,  and 
duration  of  events  (action  executions).  Thus  an  action  which  makes  no  changes  to  domain  objects 
may  still  be  a  useful  modelling  concept. 

The  effect  of  an  action  on  the  process  state  depends  on  the  state  in  which  it  is  invoked  and  on  the 
parameiers  used  in  tne  invocation.  These  parameters  serve  two  purposes  in  Gist; 

•  As  in  conventional  programming  languages,  the  parameterization  of  a  definition  permits 
users  of  the  definition  to  specialize  it  to  suit  their  needs.  In  the  case  of  an  action  the 
user,  or  invoker,  of  the  action  can  control  its  effects  by  specifying  particular  values 
(actual  parameters)  for  the  roles  (formal  parameters)  of  the  action. 

•  Reference  to  events  in  Gist’s  temporal  reference  expressions  is  done  through  a 
combination  of  action  names  and  parameter  "descriptions".  This  permits  a  much  finer 
filter  on  event  reference  than  would  reference  by  name  alone. 

An  action  declaration  consists  of  a  name  for  the  action  and  a  list  of  names  (and  types)  for  each 
formal  parameter,  or  role,  of  the  action.  It  also  may  contain  a  definition,  and  pre-  and  postconditions 
for  the  action.  Figure  2-1  illustrates  the  declaration  of  actions. 
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action 

MOVESHIP[ship,pier] 
precondition  INPORT(sn/p,p/er :  pierloc), 
definition 

jf  ship  :  DOCK  =  pier 

then  comment  no  movement  needed  end  comment 
else  update  berth  flf  ship  Jq  a  slip 
postcondition  ship  :  DOCK  =  pier: 

action 

LOADSHIP[ship, CARGO, iNCR  ;  tonnage] 
precondition  ship  :  dock  :  handles  =  cargo, 
definition 

if  CONTAINS(sh/p,cargo.$) 
then  update  tonnage  flf  CONT AINS(sh/p, cargo, $) 
iQ  tonnage  +  incr 
else  insert  CONTAINS(sh/p,cargo,/ncr); 

aCtign 

ASSIGN*CARGO[cargo,tonnage,port.from,port.to] 

definition 

begin 

require  3ship  ||  ship  :  portofcall  =  port.to; 
MOVESHIP[sh/p,ap/e^  II  pier :  pierloc  =  port.lrom]-, 
LO  A  DSHIP[sri/p,cargo, tonnage] 
end 


Figure  2-1 :  Action  Declaration  in  Gist 
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The  body  of  an  action  definition  is  constructed  from  the  primitive  statements  of  Gist  and  forms  for 
combining  them  into  complex  process  descriptions.  The  first  action  declaration  defirres  an  action 
named  MOVESHIP.  The  action  has  two  parameters,  of  types  "ship"  and  "pier".®  This  action  is 
intended  to  represent  the  activity  of  relocating  a  ship  at  a  given  pier  in  a  port.  The  definition  is  a 
simple  conditional.  If  the  ship  is  already  docked  at  the  indicated  pier,  nothing  happens;  otherwise,  the 
berth  of  the  ship  is  "updated"  to  be  some  (unspecified)  slip. 

Tnis  is  an  inadequate  definition  of  the  intended  activity,  for  two  reasons.  First,  it  fails  to  restrict 
.which  ships  can  be  moved  to  a  given  pier.  The  intent  is  that  MOVESHIP  is  describing  activity  within  a 
port;  it  is  not  to  be  used  to  relocate  a  ship  across  thousands  of  miles.  This  deficiency  is  overcome  by 
the  use  of  a  precondition  that  states  the  desired  relationship  between  the  ship  and  pier  used  as 
parameters- namely,  that  the  ship  must  be  in  the  port  in  which  the  pier  is  located. 

The  second  problem  is  the  non-determinism  of  the  slip  chosen  as  the  new  berth  for  the  ship 
Certain  referents  of  the  expression  "g  slip"  will  not  achieve  the  intent  of  this  action,  which  is  to 
relocate  the  ship  at  the  indicated  pier.  A  more  restrictive  expression  could  be  used  (restricting  the 
referents  to  slips  at  the  desired  pier)  or.  as  in  the  example,  the  same  goal  can  be  achieved  with  a 
postcondition  stating  that,  when  the  action  is  completed,  the  ship’s  dock  must  be  the  desired  pier.  In 
either  case,  it  is  unnecessary  to  incorporate  in  this  action  the  restriction  that  only  one  ship  may  be  in  a 
slip  at  a  time.  That  was  stated  as  a  global  constraint  on  the  attribute  "berth",  and  thus  serves  to 
restrict  the  non-determinism  in  this  action.  Any  attempt  to  invoke  this  action  in  a  situation  in  which 
there  are  no  empty  slips  at  the  desired  pier  would  be  anomalous,  as  would  an  attempt  to  use  it  with  a 
ship  and  pier  not  satisfying  the  precondition. 

The  second  action,  LOADSHIP,  is  intended  to  capture  the  change  of  process  state  which  occurs 
v/hen  cargo  is  added  to  a  ship.  In  this  case,  all  that  is  modeled  is  an  update  of  the  tonnage  of  the 
given  cargo  on  the  ship,  so  that  the  new  tonnage  in  the  relation  CONTAINS  is  the  sum  of  the  previous 
tonnage  and  the  increment  loaded  (or  just  the  increment  loaded  if  the  ship  did  not  contain  any  of  the 
given  cargo).  To  capture  the  intended  restriction  in  our  domain,  a  precondition  requires  that  the  ship 
be  docked  at  a  pier  which  handles  the  specified  cargo. 

Finally,  the  action  ASSIGN-CARGO  captures  the  process  of  getting  a  specified  tonnage  of  a  given 
cargo  loaded  onto  a  ship  bound  from  one  port  to  another.  The  body  of  this  action  begins  with  a 


The  rules  for  naming  and  giving  the  type  of  formal  parameters  of  actions  are  the  same  as  the  rules  used  everywhere  else  in 
Gist  for  variable  and  role  names. 
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requirement  that  there  be  some  ship  having  the  target  port  as  a  port  of  call.  It  then  uses  the 
previously  defined  actions  to  move  any  such  ship  to  any  pier  in  the  source  port,  and  to  load  the  cargo 
onto  the  ship.  In  this  example,  both  the  ship  and  pier  are  specified  by  descriptive  references  which 
are  likely  to  have  multiple  referents.  The  global  constraints  together  with  the  preconditions  and 
postconditions  of  actions  combine  to  restrict  the  non-determinism  allowed  by  the  definition  alone. 
Thus: 

*  the  ship  selected  would  have  to  be  located  in  the  source  port.  (Precondition  of 
MOVESHIP) 

*  the  pier  selected  would  have  to  handle  the  indicated  cargo.  (Precondition  of  LO  ADSHIP) 

■  the  pier  selected  would  have  to  have  at  least  one  unoccupied  slip.  (Global  constraint  on 
the  "berth"  attribute) 

*  the  ship  selected  would  have  to  be  capable  of  carrying  the  indicated  cargo  (Global 
constraint(s),  such  as  the  non-mixing  of  fuel  and  grain  cargos) 

Clearly,  tbe  specifier  has  considerable  leeway  in  Gist  in  defining  the  dynamics  of  a  process.  It  can 
be  done  with  the  method  used  in  programming  languages- -making  every  reference  (sufficiently) 
deterministic  within  its  local  context  so  that  the  global  behavior  proceeds  as  desired.  The  specifier 
can  also  use  greater  non-determinism  in  his  referring  expression,  but  bound  his  action  definitions 
with  preconditions  and  postconditions  which  ensure  proper  global  behavior.  Finally,  the  specifier 
may  use  global  constraints  to  restrict  the  non-determinism  present  in  his  action  definitions.  The 
remainder  of  this  section  describes  the  variety  of  constructs  which  may  be  used  to  compose  action 
definitions. 

2.8.1  Primitive  Statements 

The  primitive  statements  of  Gist  permit  classification  and  declassification  of  objects,  addition  and 
deletion  of  attribute  values,  addition  and  deletion  of  relationships,  and  creation  and  destruction  of 
objects.  In  each  case,  the  primitive  statement  specifies  a  transition  from  a  state  S  to  a  state  S’,  with 
no  intervening  states.  In  many  cases,  the  primitive  statement  may  involve  some  non-determinism, 
thereby  specifying  multiple  possible  state  changes. 

2. 8. 1.1  Object  Creation 

The  create  statement  specifies  the  creation  of  new  objects.  A  single  create  statement  can  specify 
creating  one  or  more  new  objects,  and  establishing  relationships  among  the  new  object(s)  and 
existing  ones.  The  new  objects  are  created  as  part  of  a  single  state  transition.  In  other  words,  the 
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create  statement  specifies  a  mapping  from  any  state  S  to  state  S'  that  is  identical  to  S  except  for  the 
addition  of  the  newly  created  objects,  their  classification  into  the  indicated  type(s),  and  the  addition  of 
the  new  relationships. 

Fo.^  example,  the  statement 

create  ship  ||  ship  :  capacity  =  30000, 
ship  :  REGISTRY  =  USA, 
ship  :  PORT.HOME  =  Seattle 

would  specify  the  creation  of  a  new  ship  having  a  capacity  of  30000  tons,  a  USA  registry  and  a  home 
port  of  Seattle.  The  new  ship  would  not  be  involved  in  any  other  relationships  initially. 

2. 8. 1.2  Object  Destruction 

The  destruction  of  an  existing  object  is  specified  by  another  primitive  statement  in  Gist.  The 
"destroy"  statement  p>ermits  the  specification,  via  an  object  expression,  of  some  object  to  be 
destroyed.  If  the  expression  has  multiple  referents,  then  one  of  the  referents  is  destroyed.  If  it  has  no 

referents,  then  the  destroy  statement  is  itself  anomalous.  A  literal  object  may  never  be  destroyed. 

( 

Destruction  of  an  object  means  eliminating  ail  classification  of  it  as  an  instance  of  any  type,  and 
removing  all  relationships  involving  it.  This  in  turn  means  that  a  process  has  no  way  of  referring  to  an 
object  following  its  destruction  except  through  variables  that  already  referred  to  it  prior  to  its 
destruction,  or  by  temporal  reference  (see  section  2.9).  For  instance; 
destroy  Seattle  PORT.home 

would  (non-deterministically)  eliminate  some  ship  whose  home  port  is  Seattle.  Following  execution  of 
the  "destroy"  statement,  even  the  expression  "a  ship"  would  not  have  the  destroyed  ship  as  a 
referent. 

2. 8. 1.3  Adding  Relationships  and  Classifications 

Addition  of  new  information  about  existing  objects  is  accomplished  with  an  "insert"  statement. 
The  new  information  may  consist  of  an  additional  classification  for  an  object  or  a  relationship 
between  objects  As  with  the  "create"  statement,  the  relationships  are  specified  by  means  of 
propositions.  For  example,  the  statement: 
insert  CONTAINS(sh/p, cargo. /ncr) 

would  add  a  relationship  between  the  referents  of  the  variables  "ship",  "cargo",  and  "incr"  to  the 
CONTAINS  relation. 

An  additional  classification  for  an  object  can  also  be  added  by  the  "insert"  statement: 
insert  port  jsa  po  rtof ent  ry 
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would  classify  the  referent  of  "port"  as  an  instance  of  the  type  "portofentry".^ 

2.8.1 .4  Removing  Relationships  and  Ctassifications 

A  relationship  can  be  removed  by  means  of  the  "delete"  statement. 
delete  (a  ship) :  portofcall  =  Seaff/e 

would  remove  (non-deterministically)  some  ship  from  having  Seattle  as  a  port  of  call. 

"delete"  may  also  be  used,  by  analogy  with  "insert",  to  declassify  an  object  as  an  instance  of  some 
type.  An  execution  which  would  leave  an  object  with  no  classification,  however,  would  be 
anomalous. 

2. 8. 1.5  Updating  Relationships 

Another  useful  change  of  state  is  the  update  of  a  relationship  between  objects.  This  has  the  effect 
of  removing  an  existing  relationship  and  adding  a  new  one.  The  "update"  statement  specifies  the 
relationship  to  be  updated,  by  means  of  a  proposition,  the  role  in  that  relationship  to  be  altered,  and 
the  new  value  to  fill  that  role. 

update  BERTH  gf  sh/p  ifl  a  s//p 

would  change  the  slip  at  which  the  ship  referred  to  by  “ship"  was  berthed  to  a  non-deterministically 
specified  slip.’° 

update  TONNAGE  of  CONTAINSfsh/p.carQO.S)  to  tonnage  +  incr 
would  change  the  quantity  of  the  cargo  referred  to  by  "cargo"  on  the  ship  referred  to  by  "ship"  to  the 
sum  of  its  previous  value  (referred  to  by  the  use  of  "tonnage"  as  a  variable  in  the  expression  giving 
the  new  value)  and  the  amount  "incr". 

If  the  relationship  in  an  update  does  not  hold,  the  update  serves  to  add  new  information  without 
deleting  anything. Conversely,  if  the  relationship  to  be  added  already  exists,  the  update  statement 
serves  solely  to  delete  the  old  relationship.  Finally,  if  the  information  to  be  deleted  is  identical  to  that 
being  added,  the  update  statement  specifies  no  change  to  the  process  state. 


®it  IS  not  necessary  that  additional  classifications  be  subtypes  of  existing  classifications,  although  that  is  the  most  common 
usage 

^^The  "new”  slip  could  be  the  same  slip  at  which  the  ship  was  berthed  prior  to  the  execution  of  the  update  statement. 

^'in  this  case,  of  course,  the  expression  specifying  the  new  object  may  not  use  the  role  name  as  a  variable  to  refer  to  the 
previous  object. 
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2.8.2  Action  Invocation 

A  defined  action  is  invoked  by'  a  statement  which  specifies  the  action  name  and  an  actual 
parameter  for  each  of  the  action's  formal  parameters.  Each  actual  parameter  is  specified  by  an 
object  expression.  The  invocation  is  non-deterministic,  allowing  any  referent  of  each  expression  to 
serve  as  the  referent  of  the  corresponding  formal  parameter.  If  any  of  the  actual  parameter 
expressions  is  anomalous,  then  the  invocation  statement  is  anomalous. 

The  invocation  specifies  the  behavior  specified  by  the  action’s  definition. 

LO  A  DSHIP[sh/p, cargo, tonnage] 

indicates  the  execution  of  the  behavior  defined  by  the  action  LOADSHIP  using  the  referents  of 
"ship",  "cargo",  and  "tonnage"  as  actual  parameters. 

2.8.3  Compound  Statements 

Gist  provides  a  variety  of  compound  statements  to  permit  specification  of; 

•  Sequential  state  changes.  A  process  encompasses  multiple  state  transitions,  not  just  a 
single  transition  from  an  initial  to  a  final  state. 

•  Conditional  state  changes.  How  a  process  alters  a  state  may  be  conditioned  by  the  state. 

•  Alternative  state  changes.  The  activity  of  a  process  may  be  non-deterministic  in  certain 
situations. 

The  statement  syntax  of  Gist  includes  forms  for  specifying  such  state  changes. 

2.8.3. 1  Conditional  Behavior 

The  conditional  statement  permits  selection  of  an  activity  based  on  the  current  process  state.  The 
simplest  form  of  conditional  statement  consists  of  a  predicate  together  with  a  statement  to  execute  if 
that  expression  is  TRUE  and/or  a  statement  to  execute  if  it  is  FALSE.  In  addition  to  conditioning  the 
behavior,  the  conditional  statement  may  produce  an  augmented  variable  reference  environment  lor 
the  selected  statement.  If  the  predicate  is  TRUE  subject  to  some  assignment  of  values  to  variables 
(see  section  2.7),  the  "then  statement”  is  executed  with  that  assignment  augmenting  the  previously 
existing  variable  assignment.  Analogously,  if  the  predicate  is  FALSE  subject  to  some  assignment  of 
values  to  its  variables,  the  "else  statement"  is  executed  in  an  augmented  variable  context.  Since 
there  may  be  multiple  distinct  assignments  subject  to  which  a  predicate  is  TRUE,  or  multiple 
assignments  subject  to  which  it  is  FALSE,  the  augmented  assignment  may  be  non-deterministic.  If 
the  predicate  is  TRUE,  but  the  "then  statement"  is  anomalous  for  all  assignments  which  make  it 
TRUE,  the  conditional  statement  is  itseil  anomalous.  Anafcgously,  if  the  predicate  is  FALSE  but  the 
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"else  statement"  is  anomalous  for  all  assignments  which  make  it  FALSE,  the  conditional  statement  is 
anomalous.  For  example, 

if  3  ship  II  CONTAINS(sh/p,  Wheal, ^tonnage  ||  tonnage  >  5000)  A 
INPORT(sh/p,  Seattle) 
then  insert  shin  :  portofcall  ■  port 
else  ASSIGN-CARGO[tVhear,  5000,  Seattle,  port] 

would  test  whether  there  was  a  ship  in  Seattle  which  contained  at  least  5000  tons  of  Wheat  If  so, 
some  such  ship  would  get  the  referent  of  "port"  added  to  its  ports  of  call.  If  not,  the  action  ASSIGN- 
CARGO  would  be  invoked  to  load  wheat  onto  a  ship  in  Seattle  bound  for  that  port.  If  there  were  one 
or  more  such  ships  in  Seattle,  but  (because  of  constraints)  it  was  not  possible  to  assign  the  new  port 
of  call  to  any  of  them,  then  the  if  statement  itself  would  be  anomalous. 

2.8.3. 2  Sequential  Behavior 

As  in  most  programming  languages,  the  sequential  execution  of  distinct  statements  is  specified  by 
a  block  statement,  which  is  simply  a  sequence  of  statements  bracketed  by  "begin"  and  "end".  The 
lexical  order  of  appearance  of  individual  statements  in  the  block  specifies  the  order  of  statement 
execution,  each  statement  being  executed  in  the  process  state  resulting  from  the  execution  of  its 
predecessor. 

2. 8. 3. 3  Point  Invariants 

The  primary  restriction  of  non  determinism  in  Gist  specifications  arises  from  the  various  forms  of 
constraint  declaration,  which  preclude  otherwise  permissible  executions.  The  declared  constraints 
restrict  non-determinism  throughout  their  scope;  they  are  not  tied  to  any  particular  state  of  the 
process.  Point  invariants  specify  conditions  which  are  required  or  prohibited  only  at  particular  states 
of  the  process.  While  point  invariants  appear  in  Gist  as  statements,  they  do  not  specify  any  state 
transition.  They  limit  non-determinism  in  a  specification  by  being  anomalous  if  executed  in  a  state  in 
which  the  predicate  is  FALSE  (in  the  case  of  a  requirement)  or  TRUE  (in  the  case  of  a  prohibition). 

Point  invariants  serve  a  second  purpose  in  a  Gist  specification.  When  the  invariant  is  satisfied, 
(one  of)  the  variable  assignment(s)  subject  to  which  the  predicate  was  satisfied  augments  the  existing 
variable  assignment  for  the  remainder  of  the  lexical  scope  in  which  the  point  invariant  appears.  A 
given  point  invariant  may  be  included  in  a  specification  for  either  of  these  two  purposes--limiting  non¬ 
determinism  or  augmenting  variable  assignment- -or  for  both  purposes. 

For  eXi'^mple,  the  point  invariant: 

reouire  3ship  ||  ship  :  portofcall  *  port.to 
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appearing  as  a  statement  would  make  anomalous  any  execution  which  reached  that  control  point  in  a 
state  in  which  no  ship  had  the  referent  of  "port.to"  as  a  port  of  call.  If  there  were  such  ships, 
however,  there  would  be  one  continuation  of  the  execution  for  each  such  ship.  In  each  continuation, 
the  variable  “ship"  would  refer  to  the  corresponding  ship  for  the  remainder  of  the  lexical  block  in 
which  the  point  invariant  appears. 

2. 8. 3. 4  Alternative  Behavior 

Much  of  the  non-determinism  in  a  process  is  specified  through  use  of  non-deterministic  object 
expressions  in  predicates  and  as  actual  parameters  of  actions.  Non  determinism  also  results  from  the 
use  of  quantified  variables  in  predicates  which  establish  referents  for  those  variables.  However,  non- 
determinism  does  not  always  factor  so  nicely,  as  in  the  English  example  "Either  buy  a  second  car  or 
move  closer  to  v,(ork".  The  choice  block  permits  this  kind  of  specification.  The  choice  block  specifies 
execution  of  any  one  of  the  statements  in  the  block.  The  lexical  order  in  which  the  statements  appear 
has  no  significance.  If  every  statement  in  the  block  is  anomalous,  the  choice  block  is  itself 
anomalous. 
begin 

require  3  ship  |1  ship  :  port.home  =  Seattle: 
choose  • 
destroy  ship: 

update  port.home  si  ship  tg  a  port  ||  port  ^  Seattle 
end  choose 

end 

The  above  example  specifies  either  of  two  possible  transitions:  a  Seattle  based  ship  is  either  to  be 
destroyed  or  assigned  a  new  home  port. 

2. 8. 3. 5  Preferential  Behavior 

A  situation  which  is  similar  to  alternative  behavior  is  one  in  which  multiple  alternatives  are  possible, 
but  these  alternatives  can  be  ordered  by  preference.  An  English  example  is  "Try  to  move  closer  to 
wo'k.  but  if  that  isn’t  possible,  buy  a  second  car".  This  is  expressed  in  Gist  by  a  preference  block. 
The  preference  block  permits  a  specification  to  "control"  the  effect  of  anomaly.  It  specifies  the 
execution  of  the  first  (in  order  of  lexical  appearance)  statement  in  the  block  which  is  not  anomalous. 
Which  statement  this  is  is  in  general  dependent  on  the  current  process  state.  If  every  statement  in  the 
block  is  anomalous,  then  the  preference  block  itself  is  anomalous. 
bgq,in 

require  3  ship  ||  ship  :  port.home  =  Seattle, 
attempt 

update  port.home  of  ship  1q  g  port  ||  port  ^  Seattle', 
destroy  ship 
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end  attempt 
end 

This  example  is  identical  to  the  "choose”  block  above,  except  that  the  order  of  statements  in  the 
"attempt"  block  is  significant.  In  this  case,  we  have  specified  a  preference  for  reassigning  the  ship 
over  destroying  it. 

2. 8. 3. 6  Non-primitive  Granularity 

The  domain  model  of  typed  objects  and  associations  has  a  "basic"  processing  granularity.  The 
.primitive  transitions  at  this  level  are  insert,  delete,  update,  create,  and  destroy.  The  ideal  process 
being  specified,  however,  may  have  a  coarser  granularity.  That  is,  some  conceptually  indivisible  state 
transition  in  the  ideal  can  only  be  described  in  terms  of  multiple  primitive  transitions. 

This  issue  must  be  faced  in  the  specification  language  because  domain  constraints,  temporal 
reference,  and  demon  triggers  are  naturally  defined  with  respect  to  states  of  the  ideal  process.  But 
independent  of  this  it  is  important  to  capture  the  granularity  of  the  ideal  process  in  the  specified 
process.  The  primary  reason  for  this  is  the  enhancement  of  maintainability.  Adding  a  new  constraint 
or  demon  to  a  specification  with  the  wrong  granularity  wifi  not  yield  the  desired  new  specification. 

Rather  than  indicating  when  (particular)  constraints  and  demons  are  to  be  checked,  the  specifier 
should  define  indivisible  database  transitions  matching  the  granularity  in  the  ideal  process.  The 
resulting  specification  will  define  a  process  having  no  spurious  intermediate  states. 

In  Gist,  non  basic  granularity  is  specified  by  enclosing  multiple  statements  within  "atomic"  ...  end 
atomic".  The  collection  of  individual  transitions  specified  by  the  bracketed  statements  specifies  a 
single,  indivisible  state  change.  For  example,  a  ship’s  home  port  and  country  of  registry  could  be 
simultaneously  changed  by; 
atomic 

update  REGISTRY  gf  ship  Jg  couniry.new, 
update  PORT. HOME  gf  ship  tg  pon.new 
end  atomic 

2.8. 3. 7  Iterative  Behavior 

The  iteration  statement  consists  simply  of  a  "generator"  of  the  objects  over  which  the  loop  runs 
and  a  body,  a  statement  which  is  executed  on  each  iteration.  There  are  two  distinct  types  of  iteration 
in  Gist:  iterations  over  the  changing  state  of  the  data  base  and  iterations  over  the  state  of  the  data 
base  before  the  iteration  begins. 
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To  understand  this  distinction,  consider  the  following  (ambiguous)  sentence:  "Move  ships  so  that 
every  ship  in  port  containing  corn  which  is  not  at  pier.2  is  relocated  there."  The  ambiguity  (of  interest 
in  this  section)  is  that  of  whether  it  is  intended  to  achieve  a  state  in  which  all  ships  containing  corn  are 
at  the  indicated  pier,  or  if  just  those  not  originally  there  are  to  be  relocated. 

The  basic  distinction  between  the  two  iteration  types  is  whether  the  predicate  is  applied  to  the 
initial  state  (before  the  iteration  begins)  or  whether  it  applies  to  the  (potentially  altered)  state  at  the 
start  of  each  repetition.  In  the  first  case. 

loop  3  ship  II  INPORT(sh/p,porr)  A 

CONTAINS  (ship.  Corn,  $)  A 
ship  :  DOCK  ^  pier.2 

sla 

attempt 

MOVESHIF[ship,pier.2]; 

begin 

MOVESHIP[a  ship,  a  pier}; 

MOVESHIP[sh/p,p/er.2] 

end 

end  attempt 

This  iteration  would  (if  possible)  move  all  ships  containing  corn  and  not  initisily  located  at  pier.2  to 
that  pier.  They  would  be  moved  one  at  a  time,  in  an  unspecified  order.  If  possible,  a  ship  would 
simply  be  moved  to  the  pier,  without  disturbing  other  ships.  If  necessary,  however,  some  ship  could 
be  moved  to  make  room  for  the  new  ship.  Since  the  ship  being  moved  could  well  be  one  which 
contains  corn  (including  one  moved  to  the  pier  on  a  previous  iteration),  there  is  no  guarantee  that  the 
loop  terminates  with  all  ships  containing  corn  at  the  pier.  It  is  only  guaranteed  that  each  will  have 
been  at  the  pier  during  one  of  the  iterations. 


If  the  word  "loop"  is  replaced  by  the  word  "while”,  the  other  iteration  semantics  obtains: 

while  3  ship  ||  INPORT(sh.'P,porf)  A 

CONTAINS(sh/p,  Corn.  S)  A 
ship  :  DOCK  *  pier.2 
dfi 

attempt 

MOMESWPlship,  pier.2]: 
begin 

MOVESHIP[ash/D,  a. oier); 

MOVESHIP[sh/p,p/er.2] 

end 

end  attempt 

fn  this  case,  a  new  ship  is  computed  at  the  beginning  of  each  repetition.  The  iteration  will  terminate 
as  soon  as,  but  not  before,  all  corn  carrying  ships  are  docked  at  pier.2. 


2  28 


GIST  SPECIFIER’S  MANUAL 


2.9  ADVANCED  TOPICS 

Gist  contains  several  important  specification  concepts  not  covered  in  this  introductory  manual.  In 
this  section,  the  most  prominent  of  these  are  mentioned. 

2.9.1  Sets  and  Sequences 

The  concepts  of  set  and  sequence  are  primitive  to  Gist.  Expressions  can  be  written  whose 
referents  are  sets  or  sequences  of  objects  of  some  type.  The  elements  of  sets  and  sequences  may 
themselves  be  sets  or  sequences.  The  need  for  sets  is  rarely  felt  in  Gist,  because  non-deterministic 
expressions  can  be  thought  of  as  referring  to  "sets”.  Sequences,  however,  are  needed  to  specify 
certain  kinds  of  ordering  information. 

2.9.2  Multiple  Lines  of  Control 

Gist  has  a  concept  called  "agent"  which  permits  specification  of  processes  which  involve  multiple 
lines  of  control.  An  agent  is  composed  of  a  collection  of  actions,  which  specify  that  agent  s 
"capabilities",  and  s,  collection  of  "demons",  each  of  which  specifies  how  the  agent  behaves  in 

I 

response  to  changes  in  the  process  state.  For  example,  each  port  might  be  an  agent  in  the  ship 
domain,  reacting  to  the  arrival  of  ships  at  the  port  and  to  new  purchase  orders. 

2.9.3  Temporal  Reference 

As  a  process  executes,  information  is  being  produced  and  consumed.  In  writing  a  program  to 
perform  the  process,  a  program.mer  must  be  concerned  with  the  storage  space  required  to  hold  this 
information.  Programs  manifest  this  concern  by  using  compact  or  implicit  representations  of 
information,  by  representing  only  that  information  essential  to  correct  execution,  and,  most 
pervasively,  by  releasing  space  used  to  store  information  that  is  no  longer  needed.  In  a 
specification  language,  however,  there  is  no  reason  to  be  concerned  with  storage  space  as  a  finite 
resource.  As  a  process  executes  the  current  collection  of  objects  and  associations  changes,  to  be 
sure.  But  the  history  of  execution  and  database  states  is  conceptually  well  defined,  in  the  sense  that 
expressions  and  predicates  can  be  assigned  natural  meanings  with  respect  to  past  times  as  well  as 
with  respect  to  the  current  state.  Gist  permits  reference  to  non  current  information  by  means  of 


12 

Programming  languages  include  facilities,  such  as  block  structure  and  garbage  collection,  which  help  the  programmer 
deal  with  this  storage  allocation  problem  More  importantly,  as  we  shall  see,  programming  languages  simply  do  not  orovide 
censm  rich  constructs,  whose  counterparts  are  available  in  rraturai  language,  that  would  make  trie  storage  allocation  problem 
too  difficult  tor  Current  compiler  cepabilities. 


i 


ADVANCED  TOPICS 


2-29 


reference  to  past  process  states.  This  in  turn  is  accomplished  by  allowing  predicates  to  be  used  to 
reference  past  states  in  which  they  were  true,  and  by  permitting  reference  to  intervals  of  states  which 
constitute, events. 

2.9.4  Boundaries 

Gist  permits  the  specification,  by  object  type,  of  the  "extent"  of  an  object  -that  is,  what  other 
objects  are  an  inherent  part  of  the  object.  This  permits  the  specific,  to  tailor,  for  each  type,  the 
semantics  of  high  level  concepts  like  destroy,  object  equivalence,  and  containment. 

2.9.5  Orderings 

Gist  also  permits  the  specification  of  “orderings"  on  objects.  A  rich  sublanguage  is  provided  for 
this,  so  the  specifier  does  not  have  to  "implement"  the  concept  in  terms  of  something  more  general 
Once  defined,  the  orderings  can  be  used  for  comparing  objects  (just  as  numbers  can  be  compared 
because  they  have  a  predefined  ordering),  and  for  controlling  the  execution  order  of  iterations. 

2.9.6  Meta  Concepts 

Collections  of  declarations  may  be  named  and  parameterized,  and  then  later  specialized  to  a 
particular  purpose.  This  permits  the  definition  of  high-level  concepts  like  "labeled  binary  tree". 
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3.  GENERAL  APPROACH  TO  WRITING  GIST 
SPECIFICATIONS 


While  it  is  not  possible  to  give  step-by-step  instructions  for  the  construction  of  a  Gist  specificaton, 
an  outline  of  the  usual  approach  should  enable  a  Gist  novice  to  avoid  being  overwhelmed  by  the  task. 

The  basis  of  Gist  is  a  simple  underlying  modeling  structure,  objects  and  relationships  among  them 
in  the  task  domain  are  modeled  by  objects  and  relations  in  Gist  (a  relational  databeise-like  model). 
Change  within  the  world  is  modeled  by  creation  and  destruction  of  objects,  and  by  insertion  and 
deletion  of  relations.  Thus  Gist  specifications  are  fundamentally  operational  in  nature.  Gist’s 
expressive  power  derives  from  the  features  built  upon  this  underlying  model. 

To  determine  an  appropriate  set  of  object  classes  and  relation  names,  a  natural  language 
description  of  the  target  process  will  prove  useful.  The  description  will  be  used  only  as  a  guide  in  the 
initial  stages  of  development  and  need  not  be  complete,  detailed,  nor  even  consistent.''^  This 
linguistic  description  will  serve  basically  as  a  guide  to  the  terms  which  need  to  be  defined  in  Gist. 

3.1  IDENTIFYING  TYPES  AND  SUBTYPES 

The  first  task  of  a  specifier  is  to  decide  on  a  collection  of  object  types  that  will  capture  the  important 
objects,  or  values,  that  the  process  manipulates  A  good  rule  of  thumb  is  to  consider  common  nouns 
(particularly  concrete  nouns)  appearing  in  the  linguistic  description  as  the  names  for  object  types 

Although  the  collection  of  type  names  thus  derived  will  likely  need  augmentation  later,  it  should 
provide  a  solid  basis  for  further  development.  At  this  time,  it  is  also  a  good  idea  to  identify  any  of 
these  type  names  which  are  used  to  describe  sets  or  sequences  of  other  named  types. 

In  any  sizable  application  domain  some  names  will  refer  to  large  classes  of  objects  and  other 
names  to  subsets  of  the  same  objects.  Although  often  the  verbal  names  used  for  types  give  no  clue  to 
these  supertype  connections,  certain  patterns  should  be  considered.  Noun  pairs,  such  as  "cruise 
ship",  are  frequently  used  to  name  subtypes  of  the  second  noun,  as  are  compound  nouns.  Adjectives 
frequently  are  used  with  nouns  in  the  same  way,  as  in  "military  vessel".  It  is  important  to  identify  not 
only  which  classes  include  which  others,  but  which  sets  of  classes  are  disjoint  and  which  overlap 
without  strict  inclusion.  Often  the  use  of  Venn  diagrams  will  prove  helpful  in  this  chore. 
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For  a  serious  sotiware  development  project.  o<  course,  s  good  natural  language  specification  is  important.  In  this  section, 
however,  we  are  assuming  that  the  specifier  urxferstands  the  process  he  wishes  to  specify  quite  clearly,  but  is  unfamiliar  with 
Gist. 


3-2 


GENERAL  APPROACH  TO  WRITING  GIST  SPECIFICATIONS 


3.2  IDENTIFYING  INDIVIDUALS 

In  order  to  fully  describe  a  process,  it  is  sometimes  necessary  to  refer  to  individual  objects  (values) 
as  well  as  to  entire  classes.  The  names  of  individuals  may  be  freely  chosen  by  the  specifier,  but  the 
type  to  which  each  belongs  must  be  declared. 

Linguistic  clues  that  indicate  the  need  for  declaring  individual  instances  of  types  include  the  use  of 
proper  nouns,  mass  nouns,  and  collections  of  adjectives  (like  color  names)  used  to  modify  the  same 
type  names.  These  distinguished  individuals  are  those  which  are  used  somewhere  in  the  description 
of  process  activity  or  of  constraints  in  the  domain.  They  are  not  used  for  the  purpose  of  describing 
"test  data"  for  some  test  of  specificaton  behavior.  A  specification  may  have  no  such  individuals. 
Even  where  they  are  necessary,  it  may  not  become  apparent  until  later  stages  of  development,  when 
they  are  needed  to  describe  the  dynamic  aspects  of  the  process. 

3.3  IDENTIFYING  RELATIONS 

The  second  major  task  of  a  specifier  is  to  determine  the  interesting  ways  in  which  objects  in  ihe 
application  domain  can  be  related  to  one  another.  In  describing  a  process  in  English,  we  use  specific 
words  and  syntax  to  describe  the  ways  objects  are  related  to  one  another.  In  "ship  bound  for 
SantaBarbara"  the  phrase  "bound  for"  indicates  a  particular  relation  that  can  hold  between  ships 
and  ports- -namely,  a  ship  can  be  scheduled  to  go  to  a  particular  port.  "A  ship  based  in 
SantaBarbara"  uses  a  different  phrase,  "based  in",  to  talk  about  a  different  relation  betv/een  the 
same  two  types.  "A  ship  containing  50  tons  of  wheat"  indicates  yet  another  relation  in  this  domain  - 
ships  may  contain  specific  quantities  of  specific  cargos. 

In  other  cases  the  only  linguistic  indication  of  a  relation  will  be  a  purely  syntactic  connection,  such 
as  the  use  of  possessive  noun  phrases  or  prepositional  phrase  modifiers.  The  specifier  must  choose 
a  distinct  name  for  each  distinct  relation.  It  is  generally  wise  to  keep  type  names  and  relation  names 
distinct.  For  each  named  relation,  the  specifier  should  identify  the  most  general  named  types  which 
can  be  related  by  that  relation. 

3.4  IDENTIFYING  DERIVED  CONCEPTS 

The  next  step  is  to  look  for  any  identified  relations  which  can  be  defined  in  terms  of  other  named 
relations  (possibly  by  recursive  definition),  and  for  identified  types  v/hich  can  be  defined  in  terms  of 
other  types  and  relations.  These  situations  provide  the  basis  for  derivation  rules  in  Gist.  In  some 
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cases,  pairs  of  relations  will  -be  found  where  either  could  be  defined  in  terms  of  the  other.  A 
particularly  common  case  of  this  is  where  the  two  relations  are  inverses  of  one  another.  It  is  usually 
best  to  define  both  relations  in  terms  of  some  more  neutrally  named  relation. 

3.5  IDENTIFYING  STATIC  CONSTRAINTS 

The  declaration  of  types  and  relationships  lays  out  a  wide  variety  of  possible  process  states- -that  is, 
states  containing  collections  of  instances  of  those  types  and  relationships  between  objects  of 
appropriate  types.  However,  it  is  nearly  always  obvious  that  many  of  these  states  may  never  really 
arise.  Sometimes  this  is  because  of  physical  constraints  in  the  process  domain.  In  other  cases,  it  is 
not  physical  reality,  but  the  desired  process  which  restricts  the  potential  states.  In  either  case,  it  is 
wise  to  identify  these  constraints  at  this  stage  of  development. 

In  choosing  what  constraints  are  worth  stating  explicitly,  a  verbal  process  description  is  of  limited 
use.  Some  constraints  may  be  expressed  verbally,  but  many  are  such  "common  knowledge"  that 
they  are  left  unstated.  A  specifier  can  state  any  obvious  constraints  which  come  to  mind  before 
working  on  the  procedural  portion  of  his  specification.  But  he  should  be  on  the  lookout  for  situations 
where  he  is  writing  procedural  specification  for  the  purpose  of  "avoiding"  a  problem.  A  particularly 
common  kind  of  constraint  which  can  generally  be  identified  at  this  stage  is  a  "cardinality"  constraint. 
For  each  binary  relation  R  relating  types  T1  and  T2  (not  necessarily  distinct),  consider  how  many 
instances  of  T2  may  be  related  in  B  to  a  single  instance  of  T1 ,  and  vice  versa.  Sometimes  there  will  be 
only  a  lower  bound  on  the  number,  sometimes  an  upper  bound,  and  often  both.  When  a  relation  is  a 
function,  the  upper  bound  will  be  1 .  If  it  is  total,  the  lower  bound  will  be  1 .  One  should  also  determine 
if  there  is  a  more  restrictive  cardinality  restriction  on  R  when  considering  subtypes  of  T1  and  T2. 

3.6  IDENTIFYING  ACTIONS 

The  information  gathered  in  these  steps  provides  the  basis  for  expressing,  in  Gist  declarations,  the 
static  structure  of  the  application  domain.  Any  application  domain  will  also  have  a  variety  of  activities 
carried  out  by  processes  in  that  domain.  These  activities  change  the  state  of  the  process  in  some 
way  They  may  create  or  destroy  domain  objects,  change  object  relationships,  or  classify  or 
declassify  objects.  Furthermore,  the  execution  of  an  action  serves  to  "mark  time"  in  the  process, 
each  action  execution  being  an  "event"  in  the  process  history.  The  linguistic  process  description  can 


^^UMimately  the  entire  specification  may  be  conveniently  written  in  terms  of  the  more  neutral  relation  without  any  reference 
to  the  derived  terms 
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serve  as  a  guide  to  the  actions  which  need  to  be  defined.  In  general,  transitive  verbs  and  nominalired 
verbs  indicate  some  action  which  needs  to  be  defined.  For  each  action,  the  specifier  should 
determine  the  types  of  objects  on  which  the  action  can  operate,  any  ''preconditions''  on  such  objects 
which  restrict  the  situations  in  which  it  is  appropriate  to  perform  the  action,  and  a  statement  of  how 
the  action  changes  the  process  state. 

3.7  IDENTIFYING  DYNAMIC  CONSTRAINTS 

A  more  difficult  class  of  constraints  on  a  process  consists  of  conditions  restricting  allowable 
change  in  the  process  state.  Identifying  these,  like  identifying  static  constraints,  can  make  the 
specification  both  easier  to  understand  and  easier  to  construct  correctly.  The  simpler  forms  of  such 
constraints  to  look  for  are  restrictions  prohibiting  change  in  certain  relationships  involving  objects 
following  their  creation,  or  restricting  the  nature  of  such  change. 

3.8  IDENTIFYING  ACTIVE  PARTICIPANTS 

In  most  large  systems,  it  is  natural  to  think  of  the  behavior  as  being  produced  by  the  interaction  of 
multiple  participants,  or  agents.  These  agents  are  often  themselves  objects  in  the  application 
domain,  and  thus  can  be  classified  by  the  same  means  used  for  non-active  objects.  For  each  agent 
class,  the  specifier  should  attempt  to  identify  the  named  actions  v/hich  are  performed  by  agents  of 
that  class. 

3.9  PROGRESSING  IN  COMPETENCE 

After  follov,iing  this  approach  in  the  specification  of  a  fev;  simple  processes,  the  specifier  will 
become  sufficiently  familiar  with  the  fundamental  concepts  of  Gist  to  intermix  the  gathering  of 
information  about  his  application  domain  with  the  encoding  of  that  information  in  Gist,  He  should 
a'so  feel  free  to  be  less  rigid  about  the  order  in  which  information  is  gathered  and  encoded.  These 
steps  are  illustrated  in  the  next  chapter,  parttculary  in  the  first  example. 
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4.  CONSTRUCTING  GIST  SPECIFICATIONS 

In  this  chapter  we  wish  to  illustrate  our  approach  to  writing  Gist  specifications  (as  described  in  the 
previous  chapter)  through  three  examples.  These  examples  are  all  real,  moderate-sized  systems 
chosen  to  demonstrate  the  applicability  of  Gist  to  a  wide  range  of  military  applications.  For  each  of 
these  examples  we  describe  the  system  to  be  specified  and  how  we  applied  the  Gist  approach  to 
specification  writing  to  formulate  these  specifications.  The  description  of  the  application  of  our 
approach  to  specification  writing  is  most  detailed  for  the  first  example. 

The  actual  Gist  specifications  for  these  examples  can  be  found  in  Appendix  II. 

4.1  SOURCE-DATA  MAINTENANCE  EXAMPLE 

The  task  we  are  about  to  specify  was  chosen  to  be  a  test  of  the  existing  features  of  Gist,  to  suggest 
the  need  for  additional  features,  and  to  promote  development  and  recognition  of  principles  of  "good 
practice"  in  the  construction  of  specifications.  The  size  of  the  task,  whilst  still  small  in  comparison  to 
many  real-world  activities,  is  larger  than  "toy"  examples.  As  such,  we  begin  to  see  how  the  difficulty 
of  constructing  and  understanding  specifications  in  Gist  grows  with  the  scale  and  complexity  of  the 
task. 

The  example  we  specify  is  taken  from  [4].  It  is  concerned  with  maintaining  programmers’  source 
code,  where  the  code  is  arranged  into  a  hierarchical  structure  of  units,  files,  libraries  and  projects. 
The  user  issues  a  batch  sequence  of  commands  to  create,  modify,  and  destroy  portions  of  this 
structure.  Figures  4-1  and  4-2  summarize  the  structure  of  the  domain  and  the  user  commands  to  be 
supported. 

The  description  upon  which  we  base  our  specification  consists  of  16  pages  of  English  text,  plus  9 
pages  of  "HlPO"  diagrams  which  graphically  depict  input,  functional  processing,  and  output  of  the 
system.  Our  intention  was  not  merely  to  formalize  the  English  description,  but  rather  to  specify 
formally  the  desired  behavior  of  the  source-data  maintenance  system  implied  by  the  English.  The 
crucial  difference  is  that  we  regard  the  English  description  as  being  biased  in  many  places  towards  a 
particular  implementation.  The  disadvantages  of  this  bias  are  that  it  compromises  one’s  ability  to 
perceive  the  desired  behavior  as  opposed  to  the  chosen  implementation,  and  as  a  result  some 
portions  of  the  English  specification  are  wrong  (in  the  sense  that  although  it  is  a  specification,  it  is 
clear  that  the  behavior  implied  is  not  the  behavior  intended),  some  are  ambiguous,  and  some 
important  details  are  left  unstated,  and  that  it  overly  constrains  the  implementation. 
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Figu  re  4- 1 :  Structure  of  source-data  maintenance  domain 


4.1.1  Suppressed  details 

Before  we  commence  description  of  our  specification,  we  make  explicit  those  features  we  have 
chosen  not  to  specify.  These  fall  into  three  classes: 

1.  Implementation  details.  From  our  earlier  comments,  it  comes  as  no  surprise  that  we 
should  suppress  details  of  this  nature.  Examples  of  such  suppression  include 

•  Data  compression  by  removal  of  blanks  when  writing  code  to  disc  (this  would  be  a 
constraint  upon  an  implementation  for  an  environment  short  of  space): 

•  Unit  Accounting  Records  which  package  together  information  about  units  (in  fact 
they  are  merely  a  convenient  implementation  package,  not  objects  that  the  user 
observes). 

Of  course,  when  directing  the  implementation  of  a  specification  we  wilt  wish  to  constrain 
the  implementation  choices  in  some  ways.  To  do  this  we  would  provide  such  constraints 
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command  name 


purpose 


UPDATE 


Maintenance  of  existing  files 


subcommands  of  UPDATE: 
ADD 
PURGE 
REPLACE 
COPY-UNIT 
CHANGE 


Add  a  new  unit 
Remove  a  unit 

Replace  the  contents  of  a  unit 
Copy  a  unit 

Maintenance  of  existing  units 


subcommands  of  CHANGE: 


INSERT 

DELETE 

SHIFT 

MODIFY 

COPY-LINES 

explicit 


Insert  lines  into  unit 
Delete  lines  from  unit 
Shift  characters  left  or  right  on 
Modify  line(s) 

Copy  lines  into  unit 
insertion/deletion  of  numbered  lines 


1 ine(s) 


COPY-FILE  Copy  file  across  project 

BACKUP  Preserve  for  later  restoration  projects, 

libraries,  files  or  units 

RESTORE  Restore  preserved  state  of  projects, 

libraries,  files  or  units 

Figure  4-2:  User  commands  supported  by  the  system 

separate  from  the  specification  of  the  functional  behavior,  which  itself  leaves  maximum 
freedom  of  choice  to  the  implementor. 


2.  Interface  details.  We  aim  to  specify  the  desired  behavior  independent  of  the  interface 
with  the  external  world.  This  is  accomplished  by  modeling  the  relevant  portions  of  the 
external  world  as  another  (incompletely  described)  participant  with  whom  interactions 
occur  via  the  standard  internal  communication  mechanisms.  As  part  of  the 
implementation  of  such  specifications,  external  interfaces  are  chosen  and  the  mappings 
between  the  external  and  internal  representations  defined.  Such  concerns  should  not 
compromise  the  clarity  of  the  functional  specification.  This  leads  to  the  suppression  of 

•  the  precise  format  of  incoming  commands  (we  assume  that  we  receive  a  sequence 
of  objects  of  type  command); 


•  the  identification  of  objects  in  the  world  by  alphanumeric  names  (we  assume  that 
the  commands  provide  a  reference  to  the  object  they  are  associated  with,  just  as  ail 
modeled  objects  provide  references  to  other  objects  through  relationships); 

•  identification  of  lines  by  sequence  numbers  (again,  we  assume  that  the  commands 
reference  the  lines  in  question  directly). 

Naturally,  any  implementation  will  obviously  have  to  take  into  account  these 
requirements,  which  we  would  state  separately. 
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3.  Refinements.  We  concentrate  upon  specifying  the  "normal-case'*  behavior  of  our  world. 
For  example,  although  our  specification  must  trap  all  error  conditions,  explicit  provision 
of  diagnostic  error  messages  for  all  the  cases  is  detail  we  wish  to  suppress  for  the  time 
being,  and  would  provide  as  a  separate  refinement  of  the  normal-case  behavioral 
specification. 


4.1 .2  Plan  for  Constructing  Source-Data  Maintenance  Specification 

As  described  in  the  previous  chapter  on  writing  Gist  Specifications,  a  specification  is  organized  to 
present  the  features  of  the  task  being  modeled  iin  a  comprehensible  manner.  This  organization  is 
repeated  below,  particularized  by  the  features  of  the  source-data  maintenance  domain. 

1 .  Define  the  object  types  and  relations  to  model  the  objects  of  the  domain  (projects, 
libraries,  files  etc.)  and  the  relationships  amongst  them  (e.g.,  files  are  related  to  libraries). 

As  we  make  these  definitions  we  may  conveniently  express  some  of  the  constraints  of  the 
domain  (e  g  ,  that  every  file  belongs  to  precisely  one  library). 

2.  Define  the  "static"  constraints  on  our  domain-  static  in  the  sense  that  these  constrain  the 
state  of  objects  and  relations  at  every  point  in  time  without  reference  to  their  history  (e  g., 
lines  in  units  are  of  length  Card-Length). 

3.  Define  the  types  and  relations  to  model  the  internal  interface  with  the  environment  (user 
commands). 

4.  Define  the  actions  v,rhich  change  the  stale  of  the  world. 

5.  Define  the  "dynamic"  constraints  on  our  domain- -dynamic  in  the  sense  that  these 
constrain  how  the  world  may  change  from  state  to  state. 

6.  Model  the  active  participants  of  the  domain  who  react  to  certain  stimuli  in  the  world  and 
respond  by  invoking  actions  to  appropriately  modify  the  world. 

This  organization  is  convenient  both  as  a  framework  to  aid  understanding  of  the  specification  and 
as  a  framev/ork  to  introduce  the  Gist  language  features. 

4.1 .2.1  Modeling  objects  and  relationships  of  domain 

Figure  4-3  illustrates  the  modeling  we  aim  to  achieve  at  this  stage.  Objects  and  relationships 
among  them  within  the  task  domain  are  modeled  as  objects  and  relationships  in  the  specification 
domain.  Files  libraries,  etc.,  are  modeled  as  distinct  objects  connected  by  relations.  This  simple  yet 
powerful  basis  allows  us  to  model  task  domains  in  a  very  direct  fashion. 

The  objects  are  typed,  so  our  first  definition  is  that  of  the  types  of  objects  of  the  domain,  after  which 
we  will  define  the  relations  linking  them.  E  g.: 
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Figure  4-3:  Modeling  of  objects  and  relations  in  Gist 


type  project;  type  library;  type  file;  type  unit; 

relation  PR0JECT-LIBRARY{PR0JECT  |  project  ,  LIBRARY  |  library); 

defines  PROJECT-LIBRARY  to  be  a  relation  bet\ween  an  object  of  type  project  and  an  object  of 
type  library.  Each  position  in  the  relation  definition  is  filled  by  <identifier>  |  <typ€>.  vyhere  identifier  is 
an  arbitrary  name.  By  convention,  when  the  identifier  is  the  name  of  the  type,  the  identifier  alone 
suffices.  E.g.: 

relation  PR0JECT-LIBRARY(pR0JECT  .library)  ; 


The  relations  are  not  restricted  to  be  binary,  nor  do  they  have  any  inherent  directionality  (i.e.,  it  is 
possible  via  PROJECT-LIBRARY  both  to  derive  from  a  project  a  library,  and  to  derive  from  a  library  a 
project). 


4.1 .2.1 .1  Notation  for  types  and  binary  relations 

Often  we  have  occasion  to  define  many  binary  relations,  as  is  the  case  in  our  example.  For  this 
purpose  a  convenient  notation  permits  the  simultaneous  definition  of  a  type  and  binary  relations  it 
participates  in.  E  g.: 

type  project(LiBRARY  .classification)  ; 

declares  project  to  be  a  type,  and  declares  two  binary  relations  which  connect  projects  with  libraries 
and  projects  with  classifications.  We  refer  to  library  and  classification  as  the  attributes  of 
project.  Note  that  there  is  a  degree  of  freedom  in  choice  of  which  type  to  make  the  attribute  of  the 
others;  in  the  above  case  we  could  just  as  easily  have  made  project  be  an  attribute  of  libraries.  This  is 
purely  a  matter  of  taste  (remember  that  we  are  using  a  notatiorial  convenience  for  the  underlying  type 
and  relation  definitions,  which  themselves  have  no  preferred  directionality)  and  should  be  made  to 
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most  closely  conform  to  the  accepted  conceptualization  of  the  domain  (i.e.,  improve 
understandability).  The  notation  supports  extraction  of  information  through  attribute  relations,  e.g.: 

to  denote  a  classification  related  to  project  p  (i.e.,  going 
downhill  in  Figure  4-3)  we  would  write 

p:CLASSIFICATION 

similarly,  to  denote  a  library  related  to  project  p  (again 
going  downhill  in  Figure  4-3)  we  would  write 

PXIBRARY 

but,  to  denote  a  project  related  to  library  /  (i.e.,  going 
uphill  in  Figure  4-3) 

/"LIBRARY 

("::"  to  go  from  attributee  to  attributor) 

The  notation  is  easiest  to  remember  in  terms  of  the  follov;ing  rule 

if  PXIBRARY  =  / 
then 

/:;LiaRAflY  =  p 

The  notation  should  be  read  as  "the  object  which  has  /  as  its  library  attribute". 

Last,  we  may  also  incorporate  into  this  notation  some  simple  constraints  on  the  participation  of 
objects  in  such  relations  (over  and  above  the  implicit  constraint  by  type).  For  example,  v/ithin  our 
domain  every  project  is  related  to  exactly  one  classification.  Similarly,  every  library  is  related  to 
exactly  one  project.  However,  a  project  may  have  any  number  (including  0)  of  libraries  related  to  it. 
These  constraints--all  restricting  the  number  of  objects  that  may  participate  in  re/ations--can  be 
expressed  within  our  type/attribute  notation.  To  constrain  how  many  objects  of  the  attribute  type 
may  be  attributed  to  a  single  object  of  the  defined  type,  we  follov/  the  attribute  name  with  and  an 
appropriate  keyword.  Similarly,  to  constrain  hov/  many  objects  of  the  defined  type  may  share  as  an 
attribute  a  single  object  of  the  attribute  type,  we  follow  the  attribute  name  with  and  an  appropriate 
keyword.  Our  choice  of  keyv/ords  includes  any  (no  restriction),  unique  (precisely  one),  multiple  (one 
or  morel,  and  optional  (zero  or  one).  E  g.: 

type  project(  library  :anv  :  :un1oue  ,  classification  lunioue  :  : any  ); 

(The  use  of  and  is  intended  to  parallel  their  use  in  expressions,  so  just  as  "pilibrary" 
denotes  a  library  attributed  to  p,  "project(  library  :anv  ..."  constrains  how  many  libraries  may  be 
attributed  to  a  project.) 

One  final  remark  before  we  show  the  definitions  for  our  example  is  to  state  defaults  for  these 
constraining  keywords:  we  have  chosen  to  let  omission  of  and  following  keyword  to  be  equivalent 
to  .unique,  and  omission  of and  following  keyword  to  be  equivalent  to  ::anv. 
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4.1 .2.1.2  Type  and  attribute  definitions  for  the  domain 
We  define  here  the  types  and  attributes  for  the  domain  of  the  example  specification: 

type  proiect(  library  :anv  :  -.uni cue  .  classification); 
type  library(  file  :  any  : :  unique ) : 

type  file(  unit  :any  : :  unique  .  PASSWORD  :ODtiona1 1 : 

type  unit ( unit-contents  |  sequence  of  line  .  unit- key  |  key  loptional  . 
SOURCE-LANGUAGE  |  language  ;ODtiona1 1 : 

type  line( CHARS  |  sequence  of  character  ,  line-includes-UNit  1  essence  of  unit  ranyl 
type  language();  tvoe  key();  type  classification( ) ;  type  password(): 

Two  remarks  on  the  above: 

Notation:  sequence  fif  is  a  built-in  type  constructor.  An  object  of  type  "sequence  Qf  t"  (where  t  is 
some  type)  is  a  sequence  of  objects  of  type  t.  In  the  following  examples  we  shall  see  notation  to  allow 
construction,  modification  and  interrogation  of  sequences.  Other  type  constructors  are  ssi  and 
multiset.  Sequences,  sets,  and  multisets  are  included  in  Gist  because  of  the  convenience  they 
provide.  They  are  built-in  parameterized  types.  In  contrast,  user-defined  types  may  not  be 
parameterized  in  Gist.  This  restriction  does  not  appear  to  be  a  drawback,  at  least  in  the  examples  we 
have  considered.  We  believe  our  specification  style  circumvents  the  need  for  such  power,  since  our 
objects  are  atomic,  gaining  their  definition  from  their  relation  to  other  objects.  This  is  against  the 
trend  of  modern  typed  languages,  in  which  the  user  objects  are  complex  entities  having  structure  and 
values. 

The  LiNE-iNCLUDES-UNiT  attribute  of  line  models  the  ability  to  include  notionally  a  unit  at  that  line's 
location  by  referencing  the  unit  (so  that  for  compilation,  listing  etc.,  the  effect  is  as  if  the  contents  of 
the  referenced  unit  were  included  at  that  point).  Because  the  source-data  maintenance  system  is 
intended  to  support  top-down  programming,  it  must  be  possible  to  "include"  a  unit  which  does  not 
yet  exist.  Gist  permits  references  to  objects  that  may  not  yet  exist  (or  may  no  longer  exist)  by 
declaring  such  references  to  be  of  type  "essence  gf  t",  where  t  is  the  type  of  the  object  being 
referenced,  as  used  above  in  the  type  definition  for  line. 
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4.1 .2.2  Static  constraints 

We  use  constraints  in  specification  to  state  concisely  and  explicitly  all  the  constraints  that  the 
model,  in  reflecting  the  world,  must  satisfy.  We  saw  in  the  previous  section  some  simple  constraints 
on  how  objects  could  fill  relations.  A  more  general  language  construct  permits  the  use  of  any 
predicate  as  a  constrain*,  which  must  always  be  satisfied.  If  we  think  about  implementation,  this  may 
imply  considerable  expense  in  checking  constraints  every  time  the  world  changes  in  a  way  that  might 
violate  them.  In  implementing  constraints  we  probably  would  want  to  distribute  appropriate  checks 
throughout  the  code  at  all  potential  violation  points.  During  specification,  however,  it  is  better  to  state 
the  constraint  just  once;  and  this  aids  understandability,  reliability  and  maintainability  (having  slated  a 
constraint,  we  are  assured  that  the  specified  behavior  must  always  satisfy  that  constraint,  even  if  we 
modify  or  introduce  new  activities). 

4. 1.2. 2.1  A  "static”  constraint 

A  constraint  of  the  source-data  maintenance  world  is  that 

"All  lines  within  the  unit-contents  of  a  unit  must  be  of  length  Card-Length." 

This  we  express  by 


always  reoui red 

V  line  II  3  uni; .  integer  j|  MEMBER(un/f :  unit-contents  ,/nteger, //ne ) 

=*►  {  lenothf/ZneiCHARSl  =  Card-Length  ); 

This  exhibits  some  of  our  notation  in  use.  We  follow  the  convention  that 

-  under! ininq  denotes  "reserved  words"  of  Gist 

-  bold  lower  case  denotes  type  names 

-  SMALL  capitals  denotes  attribute  names 

-  lower  case  italics  denotes  variable  and  parameter  names 

-  BOLD  UPPER  CASE  denotes  names  of  relations,  actions  and  derivations 

-  l/:xed  Case  Italics  denotes  objects  referred  to  literally 


In  the  above  example,  always  required  introduces  a  predicate  which  must  be  true  in  every  state  of 
the  world  The  predicate  in  this  case  is  a  quantification  over  all  objects  in  our  world  of  type  line. 
MEMBER  is  a  ternary  relation  among  a  sequence,  a  location  within  that  sequence  (specified  by  a 
positive  integer)  and  the  object  at  that  location.  Thus  for  all  lines  in  our  world,  for  those  that  are  in  the 
unit-contents  (a  sequence  of  lines)  of  any  unit,  their  character  sequence  (extracted  by  taking  the 
.CHARS  attribute)  must  be  of  length  Card-Length. 

We  have  a  shorthand  v,/hich  simplifies  writing  a  predicate  of  the  form  3  <variable>  ||  ...<variable>... 
where  the  variable  occurs  only  once  in  the  scope  of  the  existential.  The  shorthand  consists  of 
omitting  the  "3  <variable>  H",  and  writing  S  in  place  of  the  variable  in  the  body.  So  the  body  of  the 
above  constraint  becomes 
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V  line  II  MEMBER(S:UNiTXONTENTS.S.//ne) 

=*•  (  CHARS)  *  Card-Length  ) 

4.1 .2.2.2  The  use  of  derivation 

A  second  example  of  a  constraint  in  our  world  concerns  the  "line-includes-unit"  relation,  the 
means  by  which  a  line  within  the  unit-contents  of  a  unit  may  reference  another  unit.  The  intended  use 
of  this  is  that  during  compilation,  listing  etc.,  the  contents  of  the  referenced  unit  be  included  at  the 
location  of  the  line.  The  constraint  we  wish  to  impose  is  that  such  inclusion  may  not  be  circular  (with 
the  obvious  meaning). 

To  express  this  constraint,  we  build  in  stages.  First,  for  convenience,  we  define  a  new  relation 
UNIT-INCLUDES-UNIT  which  relates  unit-a  to  unit-b  whenever  unit-a  contains  a  line  "including" 
unil-b.  Second,  we  form  the  transitive  closure  of  UNIT-INCLUDES-UNIT.  Last,  we  express  the 
constraint  by  simply  prohibiting  self  inclusion  (since  any  circular  chain  will  have  led  to  derivation  of 
UNIT-INCLUDES-UNIT  between  a  unit  and  itself).  To  define  the  new  relation  we  make  use  of  a  Gist 
construct  called  a  derivation,  which  is  a  means  of  automatically  inferring  some  relation  to  hold 
whenever  a  predicate  holds.  E.g.: 

relation  UNIT-INCLUDES-UNIT(includor  1  unit  ,  INCLUDED  |  unit)  ; 

derivation  DERIVE-UNIT-INCLUDES-UNIT(un/f-a  |  unit  .  unit-b  |  unit) 
whenever  3  line  ||  MEM BER(£/n/f-a: unit-contents, $,//ne)  A 

(  line -.line-includes- UNIT  =  unit-b  ) 
conclude  UNlT-INCLUDES-UNIT(un/l-a,un/f-b)  ; 


UNIT-INCLUDES-UNIT 


unit-a 


0- 


<3 


unit-b 


To  form  the  transitive  closure  of  UNIT-INCLUDES-UNIT  we  say 


L 
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derivation  DERIVETRANS-CLOSURE-UNIT-INCLUDES-UNIT (un/f-a  |  unit  .  unit-c  |  unit) 
whenever  3  uml-b  \  unit  ||  UNIT-INCLLIDES-UNIT(un(/-a,unrt-0)  A 

UNIT-INCLUDES-UNIT(u/7>/-0.unif-c) 
conclude  UNIT-INCLUDES-UNIT(unif-a,un/f-c)  ; 

Finally  the  constraint  may  be  expressed  by 

always  oroh i b i ted 

3  unit  II  UNIT-INCLUDES-UNlT(umt,un/f); 

The  use  of  derivations  is  akin  to  the  use  of  constraints  insofar  as  it  allows  the  explicit  statement  of 
the  derivation  rather  than  distributing  the  derivation  mechanism  throughout  the  code  where  it  might 
be  appropriate. 

4.1 .2.3  Modeling  user  commands 

We  model  user  commands  causing  appropriate  changes  to  the  source-data  by  making  the 
commands  into  explicit  objects.  The  user  provides  a  sequence  of  such  commands  which  the  system 
then  processes,  performing  the  appropriate  action(s)  for  each  command.  An  alternative  would  have 
been  to  define  actions  for  each  of  the  commands  and  expect  the  user  to  invoke  the  actions  directly 
(we  would  then  have  had  to  impose  constraints  on  the  order  in  which  commands  could  be  issued  - 
e  g.,  an  add  command  must  have  been  preceded  by  a  corresponding  update  command).  Our  choice 
was  motivated  by  the  nature  of  the  described  task--the  system  acts  in  a  batch-like  manner,  accepting 
a  sequence  of  commands  v/hich  it  then  processes. 


An  implication  of  this  choice  is  that  many  of  the  attributes  of  commands  must  be  of  type  "essence 
Qf  t"  rather  than  simply  "t",  because  the  command  exists  before  or  after  the  object  referred  to  (e  g., 
one  of  the  upcate-sub-commands  in  a  sequence  of  such  may  be  a  purge-command,  which  will 
continue  to  exist  beyond  the  point  of  its  processing;  however,  the  unit  will  have  been  destroyed). 

The  command  type  definitions  are  as  follows: 

type  file-spec ( FILE ,  password  : optional  ): 

( we  introduce  file-spec  to  connect  a  tile  rete-ence  with  a  password ) 

type  command()  suoert voe  gf 

<  update-command  ;  copy-file-command  ;  backup-command  ; 
restore-command  >; 

type  update-command(CURRENT. FILE-SPEC  ]  file-spec  , 

UPDATE-SUB  COMMANDS  |  seouence  of  update-sub-command )  ; 

update-sub-commancl(cuRRENT-UNiT  j  essence  of  unit, 

UNIT-KEY  1  key  .-optional ) 


'J 
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typs 


<  add-command  ;  purge-command  ;  replace-command  ; 

copy-unit-command  ;  change-command  >; 

add-command  (DATA  |  seoucnce  of  line. 

SOURCE-LANGUAGE  |  language  : optional )  ; 

purge-command( ) ; 

replace-command  (DATA  |  sequence  of  line): 

copy-unit-command(FROMUNiT  1  essence  of  unit, 

FROM-FiLE-SPEC  |  file-spec  : optional  1 : 

change-command ( change-subcommands  | 

sequence  of  change-sub-command); 

temporary-change-command()  subtype  of  <  change-command  >; 

change-sub-command  sune rtvoe  of 

<  insert-command  ;  delete-command  ; 
shift-command  ;  modify-command  ; 
copy-lines-command  ;  replace-line-command  >; 

insert-command  (DATA  |  sequence  of  line, 

sequence-location  toptional ) : 

delete-command(L)NEs  |  essence  of  sequence  of  line): 

shift-command( LINES  ]  essence  of  sequence  of  line. 
columns  I  integer): 

modify-command  (LINES  j  essence  of  sequence  of  line, 

NEW  string  1  sequence  of  character, 
starting-column  I  integer  rootional  . 

OLD  string  I  sequence  of  character  rootional  1 : 

copy-lines-command(FROMUNiT  |  essence  of  unit, 

LINES  1  essence  of  sequence  of  line, 
SEQUENCE-LOCATION  , 

FROM-FILE-SPEC  |  file-spec  rootional  1 : 

replace-line-command(OLDLiNE  |  essence  of  line,  newline  \  line) 

copy-file-command(TO-FiLE  SPEC  |  file-spec,  from-file-spec  |  file-spec): 

backup-command(OBJECT  |  essence  pf  project  U  library  U  tile): 

restore-command ( BACKUP-STATE  |  state  ,  object  (  essence  of 

project  U  library  U  tile  U  unit): 
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4.1 .2.4  Modeling  change 

The  simple  and  unified  modeling  of  the  world  as  a  set  of  objects  and  relations  among  them  permits 
a  simple  model  of  change.  The  primitive  actions  that  cause  change  are: 

•  create  ■  create  a  new  object  of  a  given  type 

•  destroy  •  destroy  an  existing  object  (and  in  so  doing  delete  all  relations  in  which  it 
participated) 

•  insert  -  insert  (in  the  state)  a  relation  among  objects 

•  delete  ■  delete  an  existing  relation  among  objects 

•  update  ■  change  the  object  filling  a  role  in  some  relation 
These  serve  to  build  up  all  the  changes  we  wish  to  model. 

4. 1.2. 4.1  Object  boundaries 

Some  conceptually  simple  and  common  activities  in  the  world  may  involve  many  primitive  actions  to 
accomplish  them,  eg,  when  deleting  a  unit  we  may  wish  the  sequence  of  lines  attributed  to  that  unit 
to  be  deleted  also.  Languages  which  use  structured  object  definitions  also  use  that  structure  to 
determine  the  extent  of  such  operations.  We  feel  this  is  a  serious  overloading  of  concepts.  Instead, 
we  explicitly  define  the  extent  or  "boundary"  of  our  structural  objects  so  that  actions  may  be  applied 
to  the  entire  collection  of  objects  and  relations  associating  them 

To  do  this  we  augment  type  definitions  with  boundary  definitions,  which  serve  to  direct  how 
operations  such  as  destroy  create,  etc  ,  are  to  affect  an  obiecf  and  its  relationships.  E  g.. 

type  unit(  ...  )  bound  eoui v  bv 

eouiv  :  UNIT  contents . 

=  lUNiT.KEY, 

=  iSOUBCELANGUAGE  ; 

tells  us  that  two  units  are  equivalent  if  their  unit  contents  attributes  are  equivalent  (a  recursive 
appi  cation  of  equivalence),  their  unit-key  attributes  are  identical  (i.e.,  if  either  has  a  key  as  such  an 
attribute,  then  they  both  must  have  one,  and  it  must  be  the  same  key-equivalence  of  keys  is  not 
sufficient)  and  their  source-language  attributes  are  identical.  The  use  of  ’'eouiv''  or "  =  "  before  the 
attribute  name  distinguishes  whether  to  apply  equivalence  testing  recursively  between  that  attribute 
of  each  object,  or  simply  test  the  attribute  values  for  identity. 

The  same  boundary  definition  will  not  necessarily  be  appropriate  for  different  operations:  e  g.,  in 
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destroying  a  unit,  we  may  wish  destroy  to  be  applied  recursively  to  the  unit-contents  attribute  but 
not  the  UNIT-KEY  or  SOURCE-LANGUAGE  attribute,  in  which  case  our  boundary  definition  for  destroy 
would  read: 

type  unit(  ...  )  bound  destroy  by  : unit -contents  ; 

note  that  for  the  purposes  of  destroy  either  we  follow  an  attribute  and  recursively  apply  destroy  to  the 
related  object  or  we  do  not;  there  is  no  distinction  corresponding  to  the  equivalent/identical 
distinction  as  appeared  in  defining  equivalence  between  two  objects.  Hence  in  defining  a  boundary 
for  destroy  we  simply  name  the  attributes  to  be  followed  without  prefixing  them  with  either  "eauiv"  or 

II  II 

s  . 


4.1 .2.4.2  The  top-level  action  to  support  user-commands 

We  define  in  our  model  an  action  SOURCE-DATA-MAINTENANCE  which  takes  as  argument  a 
sequence  of  commands  and  makes  the  appropriate  changes  to  the  source-data  as  directed  by  those 
commands.  We  specify  the  interface  to  the  user  by  defining  as  part  of  the  system  a  demon  (a 
construct  with  two  parts,  a  tnooer.  a  predicate,  which  upon  becoming  true  causes  the  response  to  be 
performed).  Its  trigger  would  be  the  user  activity  to  initiate  processing;  its  response  would  be  the 
invocation  of  SOURCE-DATA-MAINTENANCE  with  the  appropriate  command  sequence.  This 
interaction  paradigm  serves  to  clearly  delineate  the  interface  boundary  between  user  and  system,  and 
is  general  enough  to  describe  interfaces  between  multiple,  independently  active  participants.  In  our 
simple  case  an  implementation  would  undoubtedly  utilize  a  simple  subroutine  call  as  interface. 

The  definition  of  SOU  RCE-  D  ATA-M AINTEN ANCE  is  as  follows: 

action 

SOURCE-DATA-MAINTENANCE[com/7?a/7ds  |  sequence  of  command] 
def Inition 

over  commands  named  com 
<10. 

case  com  gf 

update-command  ->  UPDATE[com]: 
copy-file-command  =>  COPY-FILE[com] : 
backup-command  =>  BACKUP[com]; 
restore-command  «>  RESTORE[com] ; 
end  case  : 

The  construct  over  <sequence>  named  <variable>  dg  <statement>  iterates  through  the  sequence  in 
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order,  binding  the  variable  to  the  current  element  of  the  sequence  within  the  scope  of  the  statement. 
Here  the  effect  is  to  invoke  the  appropriate  lower  level  action  depending  upon  the  sub-type  of  the 
command. 

The  most  interesting  part  of  this  definition  lies  in  the  use  of  the  attempt  construct.  Within  Gist,  if  a 
transition  leads  to  a  state  that  violates  a  constraint,  we  say  that  the  resulting  state  is  anomalous,  and 
prohibit  that  transition.  In  some  -ases  there  may  be  more  than  one  way  of  performing  the  transition 
(e  g.,  if  we  said 

begin  require  3  unit ;  destroy  unit  end 

and  several  units  exist,  then  we  may  pick  any  one  of  them  to  be  destroyed).  If  all  possible  ways  of 
performing  a  transition  from  some  state  lead  to  anomaly,  then  that  state  itself  is  anomalous.  Thus 
anomaly  can  propagate  backwards.  Attempt  is  a  construct  that  limits  such  propagation.  We  use  it 
here  in  a  simplified  form  of  its  more  general  version, 

attempt  <statement.,>  then  <statement2>  else  <statement3> 

This  has  the  semantics  of  <statement,i>  ;  <statement2>  if  there  is  a  possible  non  anomalous  execution 
of  <statemeht^>,  otherwise  <statement2>.  We  use  attempt  in  our  example  to  limit  the  failure  of  a  user- 
command  to  that  command  alone,  rather  than  aborting  the  processing  of  the  entire  sequence  of 
commands. 

Definition  of  action  UPDATE  is  similar  to  SOURCE-DATA-MAINTENANCE.  It  is  an  iteration 
through  a  command  sequence,  invoking  the  appropriate  lower  level  command.  We  now  turn  our 
attention  to  the  actions  to  perform  the  lowest  level  commands. 

4. 1.2. 4. 3  A  simple  action 

The  purge  command  (to  get  rid  of  a  unit)  is  supported  by  the  following  action: 

action  PURGE[un:f] 

def i n 1 t i on  destroy  unn  ; 

The  simplicity  of  this  definition  is  due  to  two  factors.  First,  the  separate  statement  of  constraints 
means  we  need  not  clutter  PURGE'S  definition  with  checks  to  ensure  that  the  user  has  provided  the 
correct  unit-key  (as  required  in  this  example  for  those  units  which  have  an  optional  unit-key),  that  the 
unit  is  not  included  elsewhere,  etc.  Second,  the  separate  definition  of  a  destroy  boundary  for  type 
unit  ensures  that  when  we  state  destroy  unit,  we  also  destroy  its  unit-contents  sequence  of  lines. 
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4. 1.2. 4. 4  Adjusting  process  "granularity" 

The  ADD  command  (to  add  a  new  unit)  is  a  little  more  complex; 


action  ADD[un;f  1  essence  of  unit,  tils,  add-command'] 
def i nit  ion 

in- 

atomic 

create  unit ,  c^py-of-lines  |  sequence  of  line  |  | 

copy-ol-iines  =  add-command  -.data  A 
un/l :  UNIT-CONTENTS  *  copy-of -lines : 


insert  //7e;UNiT  *  unit 
atomic: 

if.  3  key  \  |  key  -  add-command: unit-key 
then  insert  un/f : unit-key  =  key 
find  : 


The  construct  create  unit ...  || ...  unit iunit-contents  =  ...;  is  used  to  create  a  new  unrt  and  provide 
it  with  its  UNIT- contents  attribute. 


The  interest  here  lies  in  the  use  of  the  atomic  <8talement>; ...;  <statement>  sad  atomic  construct. 
The  problem  is  that  we  must  create  a  unit  and  insert  it  as  an  attribute  of  a  file.  Because  of  our 
constraints,  all  units  must  be  attributed  to  a  file;  hence  we  must  somehow  perform  the  creation  and 
insertion  within  a  single  state  transition,  so  that  on  completion  all  will  be  well.  This  is  precisely  what 
atomic  provides--the  enclosed  statements  are  all  executed  conceptually  within  a  single  state 
transition,  so  that  constraints  are  checked  only  at  completion,  not  during  spurious  intermediate 
states.  (If  the  state  re.sulting  from  an  atomic  is  anomalous,  then  the  whole  transition  is  anomalous.) 
Thus  atomic  is  a  means  of  increasing  the  processing  "granularity"  to  a  coarser  size  than  the  primitive 
transitions  f create,  destroy,  insert,  delete  and  update V 

4. 1.2. 4. 5  Non-determinism  and  constraints 

Non-determinism  is  a  common  feature  of  Gist  specifications.  Specification  of  a  particular  object 
may  be  non-deterministic,  e.g., 

begin  require  3  variable  I  type  ;  <statement>;  <statement>; ...  end 
binds  the  variable  to  any  object  of  the  named  type  within  the  scope  of  the  following  statements.  (If  no 
such  object  exists,  it  is  an  anomaly.)  Specification  of  the  order  in  which  to  do  some  actions  may  be 
non-deterministic,  e.g., 

over  {  <object>  , ... ,  <object>  )  da  <statement>; 
iterates  through  the  set  of  objects  in  any  order. 
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The  task  we  are  specifying  may  be  non-deterministic  in  nature  (but  this  is  not  the  case  with  the 
source-data  maintenance  task).  This  is  not  the  sole  use  of  non-determinism;  often  it  is  particularly 
convenient  to  specify  some  activity  in  a  non-deterministic  manner  and  let  the  constraints  filter-out 
only  the  acceptable  paths.  This  allows  us  to  specify  the  desired  behavior  without  having  to 
algorithmically  determine  what  choice  necessarily  must  be  made.  This  latter  form  of  non-determinism 
does  occur  within  our  specification,  as  we  shall  see  next. 

4. 1.2. 4. 6  Shifting  characters  on  a  line 

An  example  of  filtered  non-determinism  is  the  specification  of  the  SHIFT  action,  to  support  the 
user-command  shift,  causing  characters  on  a  (unit’s)  line  to  be  shifted  left  or  right.  We  define  a 
relation  ISSHIFTEO  between  two  sequences  of  characters  and  an  integer,  which  holds  if  and  only  if 
the  non-blank  portion  of  the  first  sequence  is  equal  to  the  non  blank  portion  of  the  second  sequence, 
and  has  been  shifted  by  the  specified  number  of  columns- by  insertion  of  extra  blanks  if  a  positive 
number  of  columns,  deletion  of  blanks  if  a  negative  number. 


This  we  specify  by 


relation  ISSHIFTED(newchars  1  sequence  of  character, 

OLOCHARS  I  sequence  of  character,  columns-to-Shift  |  integer) 

definition 

3  old-le't-blanks  |  sequence  flf  "  " ,  old-righi-blanks  \  sequence  of  "  ", 
new-left-blanks  |  sequence  of  ”  ”,  new-right-blanks  |  sequence  of  "  . 

non-blanks  |  sequence  of  character  [  | 

-MEMBER(/7on-p/ar?As  ,$,"")  A 

oldchars  *  old-left-blanks  @  non-blanks  8  old-right-blanks  A 
newchars  -  new-left-blanks  8  non-blanks  6  new-right-blanks  A 
lencthf new-lelt-blanks)  -  lengihf old-left-blanks)  =  columns-to-shift  ; 

Observe  that  this  definition  implies  that  if  there  is  at  least  one  shifted  version  of  a  sequence  (there 
might  be  none,  if  we  tried  to  shift  a  non  blank  character  oft  the  left  of  a  sequence),  then  there  exist  an 
■nfinite  number  of  equally  valid  shifted  versions  of  the  sequence  (since  extra  blanks  can  always  be 
tacked  onto  the  end). 
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The  sole  purpose  of  this  definition  is  to  state  what  shifting  means-the  responsibility  is  left  to  the 
prevailing  constraints  of  ensuring  that  the  sequence  of  the  appropriate  length  is  inserted  into  a  line  of 
some  unit-contents  (namely,  the  one  restricting  character  sequences  of  lines  in  units  to  be  of  length 
Card-Length).  Thus,  the  shift  action  can  merely  select  a  sequence  of  characters  which  satisfies  the 
ISSHIFTED  relation  to  update  each  appropriate  line.  Notice  that  non-determinism  has  been  used  in 
two  powerful  ways  here.  First,  through  the  ISSHIFTED  relation,  to  select  an  appropriate  object 
defined  by  its  acceptance  criteria  without  specifying  how  it  should  be  computed.  Second,  the 
constraint  on  the  length  of  lines,  further  filtering  the  satisfactory  objects.  The  main  difference 
between  the  two  is  that  the  first  is  a  purely  local  acceptance  criteria  (as  defined  by  the  relation),  while 
the  second  deals  with  the  object  usage  (arbitrarily  far  into  the  future)  and  restricts  choice  to  those 
which  will  not  violate  constraint. 

The  definition  of  action  SHIFT  using  this  is: 

action  SHifyishlft-command] 
definition 

over  sh/h-command: LINES  named  line 
il2  update  : chars  fif  line  to 

some  newchars  \  sequence  of  character  |  1 

ISSHI FTED  ( newchars ,  chars ,  shill-command :  columns  )  ; 

Notation;  some  x  1  type  ||  P(x)  selects  any  object  of  the  type  that  satisfies  P(x). 

4.1 .2.4.7  The  use  of  historical  reference 

Given  that  our  modeling  is  based  upon  states  and  transitions  between  them,  it  is  particularly 
convenient  to  have  the  ability  to  extract  information  from  any  previous  state.  If  we  did  not  have  the 
power  to  make  such  "historical  references",  we  would  be  forced  to  remember  all  information  that 
might  possibly  be  needed  at  some  time  in  the  future.  This  would  both  clutter  up  the  information 
carried  along  from  state  to  state  and  complicate  our  activities  (since  they  would  have  to  save  such 
information  explicitly).  Thus  historical  reference  is  another  example  of  a  specification  technique  that 
allows  us  to  limit  our  concerns  to  only  those  which  are  of  current  importance. 

Once  we  have  accepted  the  use  of  historical  reference,  it  is  natural  to  have  the  full  power  to  refer  to 
states  as  we  have  with  any  other  type  (with  the  limitation  that  we  cannot  change  what  has  already 
happened!).  Furthermore,  observable  events  include  not  only  the  primitive  transitions,  but  also  the 
start  and  completion  of  action  invocations. 


4-18 


CONSTRUCTING  CIST  SPECIFICATIONS 


4. 1.2. 4. 8  Historical  reference  and  inserting  lines  into  units 

One  of  the  sub-commands  of  CHANQE  is  INSERT,  to  insert  a  sequence  of  lines  into  the  unit- 
contents  of  a  unit.  The  user  optionally  provides  a  specific  location  for  the  insertion  to  occur.  If  it  is 
omitted,  the  lines  are  to  be  inserted  after  the  last  line  changed  in  the  unit  since  the  start  of  the 
CHANGE  command,  or  at  the  front  of  the  unit  if  there  has  been  no  such  change. 

To  model  this  we  first  define  a  relation  between  a  uni*  and  the  latest  state  (since  last  starting 
CHANGE  on  that  unit)  in  which  the  unit  contents  then  differed  from  the  unit  contents  now: 

relation  LATEST-STATE-OF-CHANGE(  UNIT  ,  CHANGESTate  1  state) 
def inition 

changestate  ~  latest  some  slate  )|  uni7: unit-contents  ~eQuiv 

(  un;f;  UNIT-CONTENTS  ai  al  state  )  A 
state  af ter  latest  start  CHAN6E[un;f ,$]  ; 

Notation:  <expression>  as  of  <state>  causes  the  expression  to  be  evaluated  in  that  state,  latest 
<state>  ,  where  <state>  is  some  expression  denoting  a  state  or  states,  denotes  the  most  recent  such 
state,  start  <action>[<object>,...J  denotes  the  state(s)  in  which  invocation  of  that  action  (with  those 
objects  as  actual  parameters)  began,  state.,  after  state,  is  true  if  and  only  if  state,  is  more  recent  than 
statej. 

Thus  in  the  above  "state  after  latest  start  CHANGE[i;n/f,$]'’  will  be  true  if  and  only  if  state  is  more 
recent  than  the  latest  start  of  CHANGE  on  unit. 

Then,  if  such  a  state  exists,  we  may  determine  the  location  of  the  change  and  insert  the  new  lines 
after  it;  otherv/ise  insert  them  at  the  front  of  the  unit. 

4.1 .2.4.9  Historical  reference  and  backup/restore  commands 

In  the  English  specification  of  the  source-data  maintenance  system,  backup  and  restore  commands 
cause  portions  of  the  world  (libraries,  files,  etc.)  to  be  written  to  or  recovered  from  magnetic  tape.  In 
our  modeling  of  the  behavior  (as  opposed  to  implementation)  within  Gist,  backup  becomes  a  totally 
superfluous  operation,  since  with  historical  reference  we  may  refer  to  any  past  state  and  perform  a 
restoration  of  an  object  to  the  condition  it  was  in  in  that  state.  The  ramifications  of  this  for  any 
implementation  are  that  at  any  point  in  time  the  user  might  request  restoration  of  any  object  to  any 
earlier  state!  If,  however,  we  choose  to  insist  that  the  user’s  restore  commands  may  only  restore 
objects  to  the  state  they  were  in  when  explicitly  mentioned  in  a  backup  command,  the  implementation 
need  be  prepared  to  make  only  such  restorations,  rather  than  arbitrary  ones. 
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This  is  an  interesting  case,-  a  non-obvious  line  between  specification  and  implementation.  We 
follow  the  more  restrictive  style  of  restoration,  retaining  the  backup  command  to  mark  an  object  and  a 
state  by  its  invocation: 

action  BACKLIP[backup-commar)d]  ; 

A  restore  command  must  refer  to  a  state  at  which  a  backup  command  was  invoked,  and  to  an 
object  that  was  the  object,  or  within  the  object,  given  as  the  argument  to  the  backup  command; 

action  RESTORE[restore-command] 

let  obj  j  essence  of  project  U  library  U  file  U  unit 
=  resfore-command;  OBJECT 

t>recondition 

3  backup-command  ]  | 

restore-command -.backup-state  =  start  BACKUP[backup-co/nmand]  A 
(  backup-command -.OBJECT  contains  obj  ) 

as  of  resfore-command:  backup-state 

def i n it  ion 

restore  obj  aj.  gf  resfore-command; BACKUP-STATE  ; 

Notation:  restore  <ob|ect>  as  S2l  <state>  restores  the  object  to  the  condition  it  was  in  in  that  state, 
creating/destroying  objects  and  inserting/deleting  relations  to  make  the  object  equivalent  (with 
respect  to  its  type’s  boundary  definition  for  equivalence- -see  4.1. 2.4.1)  to  its  earlier  condition.  Thus 
restoring  a  file,  for  example,  will  involve  deleting  new  units  attributed  to  the  file  since  the  specified 
state  and  restoring  the  units  that  were  attributed  to  the  file  in  that  state. 

4.1 .2.4.1 0  Historical  reference  and  desired  behavior 

We  have  demonstrated  how  historical  reference  can  be  used  to  support  BACKUP  and  RESTORE 
commands.  It  can  also  support  the  "temporary"  change  option.  The  user  command  CHANGE,  to 
cause  changes  to  a  unit  (with  sub-commands  INSERT,  SHIFT,  etc.),  may  be  declared  to  be 
"temporary"  in  nature,  in  which  case  at  the  end  of  processing  the  current  batch  of  user  commands 
the  (presumably)  changed  unit  is  to  be  restored  to  its  state  prior  to  commencement  of  the  temporary 
changes. 

We  should,  however,  ask  whether  either  form  of  restoration,  either  user-directed  via  the  RESTORE 
command,  or  automatically  because  of  earlier  "temporary"  changes,  could  possibly  fail.  It  turns  out 
that  this  possibility  does  indeed  exist.  Suppose  we  have  two  units,  unit-A  and  unit-B,  and  unit-A 
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contains  a  fine  that  “includes"  unit-6.  At  this  point  we  issue  a  backup  command  for  unit- A,  or  change 
it  temporarily.  Now  if  we  delete  the  "include"  line  in  unit-A,  we  may  then  be  able  to  change  unit-B  to 
insert  a  new  line  "including"  unit-A.  Prom  this  state  it  would  be  impossible  to  restore  unit-A  to  its 
original  condition,  since  this  would  violate  our  constraint  prohibiting  circularity  of  includes. 

Should  the  attempted  restoration  simply  fail,  or  should  the  modification  of  unit-B  have  been 
prevented?  We  must  decide  which  of  these  (or  other)  alternative  behaviors  we  want.  The  English 
specification,  by  not  saying  anything,  suggests  the  first  option,  namely  restoration  can  simply  fail.  Our 
feeling  is  that  the  possibility  of  such  failure  was  never  even  recognized,  and  this  behavior  was 
dictated  by  circumstances  rather  than  choice.  Reasonable  behavior  might  be  that  in  the  case  of  user- 
issued  backup  and  restore  commands,  restore  could  fail  in  the  manner  described  above  (i.e.,  it  is  the 
responsibility  of  the  user),  whereas  in  the  case  of  temporary  changes,  it  must  always  remain  possible 
to  do  the  restoration  (we  don't  want  to  surprise  the  user  with  an  "automatic"  facility  that  fails!).  Our 
point  is  not  that  this  is  the  "right"  choice,  rather  that  the  existence  of  such  a  choice  must  be 
recognized  and  the  choice  consciously  made,  otherwise  the  resulting  system  may  exhibit  surprising 
and  inappropriate  behavior. 

Our  suggested  choice  permits  us  to  demonstrate  another  Gist  feature.  We  wish  to  v^rite  a 
constraint  to  ensure  that  restoration  (of  temporarily  changed  units)  v.'ill  always  be  possible.  To  do  this 
we  say 

always  reoui red 

admissible  RESTORE-TEMPORARILY-CHANGED-UNITS[]  ; 

where  RESTORE-TEMPORARILY-CHANGED-UNITS  is  the  action  to  perform  the  appropriate 
restoration, 

The  construct  admissible  <statement>  is  a  predicate  that  is  true  if  and  only  if  there  is  some  non- 
anomalous  way  of  executing  the  statement  in  the  current  state  of  the  worId--however,  the  statement  is 
not  actually  executed,  i.e..  the  current  state  is  not  changed,  but  a  truth  value  is  returned.  This  is  a 
simple  form  of  "future"  reference.  Often  the  easiest  way  of  predicting  a  result  of  doing  something  is 
to  extract  the  desired  information  from  the  state  in  which  it  has  been  done,  but  proceed  (with  the 
information)  from  the  state  prior  to  doing  it. 
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4. 1.2. 5  Dynamic  constraints 

The  defined  constraints  serve  to 'limit  the  possible  states  that  the  model  world  may  achieve.  We 
notionally  distinguish  between  "static"  and  "dynamic"  constraints  by  classifying  those  that  refer  only 
to  the  current  state  as  "static",  and  those  that  refer  to  several  states  (usually  the  current  state  and  the 
previous  one)  as  "dynamic". 

4. 1.2. 5.1  A  "dynamic"  constraint 

An  example  of  a  dynamic  constraint  taken  from  the  source-data  maintenance  world  is: 

"  A  unit  may  not  be  destroyed  if  it  is  included  anywhere" 

We  express  this  constraint  by  forbidding  a  transition  from  a  state  in  which  a  unit  exists  to  a  state  in 
which  that  unit  no  longer  exists  (i.e.,  has  been  destroyed  in  the  transition)  but  is  still  "included"  by 
some  line  in  the  contents  of  a  unit. 

always  prohibited 

3  dead-unit  \  essence  of  unit  1  | 

destroyed  dead-unit  A  UNIT-INCLUDES-UNIT($,deao-un/f) 

Reference  to  a  past  state  is  via  the  destroyed  predicate,  which  is  true  if  and  only  if  the  object  existed 
in  the  immediately  preceding  state  and  has  been  destroyed  in  the  transition. 

This  explicit  statement  of  the  constraint  contrasts  with  the  English  specification,  wherein  no  similar 
statement  occurred;  instead,  an  implementation  to  achieye  the  same  effect  (by  making  use  of 
reference  counts)  was  described.  This  was  particularly  inappropriate  for  seyeral  reasons:  the 
intended  behayior  had  to  be  deduced  from  the  implementation;  the  other  parts  of  code  lost  clarity 
because  they  had  to  deal  with  reference  counts;  worst  of  all,  it  was  actually  wrong  -  in  the  case  of 
destroying  an  entire  unit  no  mention  was  made  of  decrementing  the  reference  counts  of  units 
"included"  by  lines  of  the  destroyed  unit. 

4.1.3  Review  of  specification 

The  previous  section  demonstrated  the  use  of  Gist's  features  in  some  of  the  specification  of  the 
source-data  maintenance  task.  The  entire  specification  is  available  from  the  author. 

We  may  now  look  back  and  ask  the  following  questions: 

1.  How  effective  are  the  Gist  features  for  expressing  the  structure  and  behavior  of  the  task 
domain? 

2.  What  have  we  learned  about  the  task  from  having  written  a  formal  specification? 
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3.  What  diKicutties  arose  in  constructing  the  specification? 

4.  How  comprehensible  is  the  specification  to  someone  other  than  the  writer? 

5.  What  do  we  intend  to  do  with  the  formal  specification? 

4.1 .4  Implications  for  Gist 

Most  of  the  Gist  features  used  to  specify  the  source-data  maintenance  task  were  present  in  the 
language  prior  to  tackling  this  example.  Certainly  the  underlying  modeling  approach  proved 
satisfactory.  We  were  led  to  some  additions  and  notational  refinements.  These  were: 

•  essence  gf,  as  a  means  of  maintaining  references  to  destroyed  or  yet  to  be  created 
objects. 

•  boundary  definitions,  to  support  destroy,  restore,  etc. 

•  attribute  notation  for  defining  and  making  use  of  binary  relations. 

4.1.5  Implications  for  the  source-data  maintenance  task 

In  constructing  a  formal  specification  in  Gist  we  feel  we  have  developed  a  much  deeper 
understanding  of  the  task  than  we  had  from  merely  reading  the  English  description.  We  were  led  to 
recognition  of  ambiguities,  implementation  biases,  and  possible  errors  in  the  informal  English. 
Formalizing  in  Gist  forced  us  to  consider  behavioral  interactions  which  we  might  otherv^ise  have 
overlooked  (for  example,  between  restoration  and  constraints). 

It  may  well  be  the  case  that  spending  a  similar  amount  of  time  studying  the  task  (without  producing 
a  Gist  specification)  would  have  led  to  the  same  insights,  so  v/e  should  regard  the  above  observations 
as  lack  of  negative  evidence  rather  than  additional  positive  support  for  our  approach. 

4.1.6  Difficulties  of  constructing  the  specification 

A  significant  degree  of  effort  was  required  to  construct  our  specification.  We  attribute  much  of  the 
difficulty  to  the  need  tc  infer  the  desired  behavior  from  the  English  description.  As  we  have  already 
remarked,  we  found  this  description  to  be  overly  biased  towards  a  particular  implementation;  hence 
we  could  not  merely  formalize  the  description,  but  rather  had  first  to  disentangle  its  intent  and 
formalize  that. 


iv.-  . 

I 


We  were  also  hampered  by  a  lack  of  experience  of  writing  Gist  specifications.  Faced  with  a  choice 
of  alternative  ways  of  specifying  some  behavior,  we  had  little  experience  to  guide  our  choice. 
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Finally,  we  recognize  the  need  for  some  assistance  in  understanding  the  implications  of  our 
specification.  In  building  a  specification  from  descriptions  of  desired  behaviors  in  simple  cases  we 
must  be  careful  to  consider  the  possible  interactions  of  these  cases  and  ensure  that  the  resulting 
behavior  is  satisfactory. 

4.1 .7  Difficulties  of  understanding  specification 

We  have  observed  that  readers  of  our  specification  find  it  hard  to  understand- -even  other  members 
of  our  group  who  have  equal  fluency  in  Gist.  We  attribute  this  in  part  to  our  emphasis  on  easing  the 
task  of  the  specification  writer  rather  than  the  reader- -Gist  is  still  in  development  and  there  are 
undoubtedly  many  cosmetic  improvements  which  would  help.  Nevertheless,  there  is  more  to 
specification  than  merely  ensuring  we  have  an  effective  notation.  First,  specifications  may  require 
some  explanation  of  how  they  were  derived--for  example,  make  explicit  the  choices  faced  by  the 
specifier  and  his  reasons  for  choosing  one  over  another.  Second,  some  assistance  is  required  to  help 
the  new  reader  build  up  gradually  to  a  comprehension  of  the  entire  specification.  We  envisage 
several  tools  to  assist  comprehension.  For  example,  a  sophisticated  interpreter  would  permit 
exploration  of  the  behavior  of  a  specification  and  analysis  tools  could  outline  the  possible  areas  of 
interactions  among  the  features  of  a  specification. 

Finally  we  might  organize  our  specification  into  layers  of  increasing  complexity,  working  from  a 
simplified  specification  suppressing  (or  distorting)  features  in  the  higher  layers,  so  that  by  descending 
from  layer  to  layer  an  increasingly  accurate  and.oomplete  comprehension  of  the  specification  can  be 
incrementally  built  up. 

4.1 .8  Use  of  specification 

The  main  purpose  of  a  Gist  specification  is  to  serve  as  a  behavioral  description.  We  must  define 
v/hich  portions  of  its  behavior  are  "observable"  (eg.,  observable  behavior  of  the  source-data 
maintenance  specification  v/ould  presumably  include  the  creation  /  destruction  of  units,  files, 
projects,  etc.,  but  not  the  invocation  of  particular  actions  PURGE,  CHANGE,  etc.).  Given  such  a 
notion,  we  may  ask  whether  an  implementation  exhibits  the  same  observable  behavior.  If  we  can 
demonstrate  that  it  does,  we  have  validated  that  implementation.  We  have  not  as  yet  developed  a 
syntax  for  expressing  the  observable  portions  of  behavior  of  a  Gist  specification. 

One  of  our  long-term  research  aims  is  to  be  able  to  take  formal  specifications  of  behaviors  written 
in  Gist,  together  with  relevant  details  suppressed  from  our  behavioral  description  (namely,  interface 
and  implementation  requirements,  and  refinements  of  the  described  normal-case  behavior)  and 
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transform  them  to  achieve  efficient  implementations.  We  are  sure  that  such  transformations  will 
require  human  guidance,  since  the  distance  between  our  specifications  and  any  tolerable 
implementations  is  very  wide. 

For  example,  consider  removing  Gist  constraints.  Our  aim  would  be  to  replace  them  by  checks  at 
all  possible  choice-points  in  the  program  that  could  lead  to  violation  of  the  constraint.  In  cases  where 
we  cannot  construct  an  appropriate  predicate  at  the  choice  point  to  recognize  which  choices  will  lead 
to  anomaly  we  would  have  to  resort  to  other  mechanisms,  such  as  back-tracking.  A  detailed 
.  transformation  which  illustrates  these  problems  is  presented  in  [1  ]. 

4.2  HOST-IMP  SPECIFICATION 

4.2.1  Overall  organization  of  specification 

First  we  define  general  message-passing  features  common  to  imps  and  hosts,  then  we  describe  the 
specific  features.  We  encompass  the  effects  of  user  interaction  and  hardware  failure  as  random 
activities  with  which  the  hosts  and  imps  must  be  able  to  cope. 

4.2.2  General  message-passing  features 

We  model  message- passing  by  defining  types  item  and  node.  Objects  of  t^'pe  node  transmit 
objects  of  type  item  between  themselves.  At  this  general  level  each  item  has  two  attributes--a 
MESSAGE  (further  details  of  which  we  will  not  need  at  this  level)  and  an  address- -the  node  to  which 
the  item  is  to  ultimately  be  delivered.  The  Gist  construct  aoent  is  used  to  describe  nodes,  in  order  that 
they  may  be  independently  active  processes. 

nodes  -  we  denote  connections  between  nodes  via  relation  CONNECTED.  For  simplicity  v^e 
prohibit  a  node  from  being  connected  to  itself. 

Each  node  has  the  following  attributes' 

•  PENDING  -  those  items  yet  to  be  dealt  with  by  the  node, 

•  TO-BE  SENT  -  items  to  be  sent  elsewhere  by  the  node. 

•  MY-MESSAGES  •  messages  extracted  from  items  which  are  addressed  to  this  node. 


Each  node  has  the  following  actions  and  demons: 

•  action  TRANSMIT  -  this  causes  ari  item  to  be  transmitted  to  a  (connected)  node. 
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•  pendino-demon  RECEIVE  -  this  demon  is  triggered  when  a  transmission  directed  to  this 
node  is  begun  (i.e.,  a  TRANSMIT  action  is  invoked,  with  this  node  as  the  destination).  Its 
response  is  to  await  completion  of  the  TRANSMIT.  If  the  completion  was  normal,  then  the 
‘transmitted’  item  is  inserted  into  the  node’s  pending  attribute.  (If  the  completion  was 
abnormal,  nothing  is  done,  modeling  the  loss  of  a  transmission  if  the  transmitter  fails 
during  transmission), 

•  pending-demon  PROCESS-PENDING  -  this  demon  is  triggered  when  a  new  item  is 
added  to  the  node's  pending  attribute.  Its  response  is  to  remove  the  hern  from  the 
pending  attribute  (cleaning  up),  and  on  the  basis  of  whether  or  not  the  item  is  addressed 
to  this  node,  insert  it  into  the  my-messages  attribute  or  the  to-be-sent  attribute. 

•  pending-demon  SEND  -  this  demon  is  triggered  when  a  new  item  is  added  to  the  node’s 
to-be-sent  attribute.  Since  the  response  in  this  domain  will  turn  out  to  be  so  dependent 
on  whether  the  node  is  a  host  or  imp,  we  will  only  present  the  definitions  of  SEND 
particular  to  hosts  and  imps. 

•  action  ACTIVATE  •  this  action  is  to  be  invoked  when  the  agent  is  activated.  It  clears  the 
to-be-sent  and  pending  attributes,  and  waits  Reiay-Sei-Time  (a  hardware  requirement). 


A  separate  agent  hardware  failure  is  defined  to  model  the  random  hardware  failure  of  nodes. 
Two  demons  are  provided,  one  to  (at  random)  deactivate  a  node,  and  the  other  to  (re)activate  a  node. 
The  intention  is  that  this  specify  part  of  the  environment  in  which  the  nodes  operate,  not  that  this  be 
something  the  implementor  must  incorporate  into  his  software! 


4.2.3  Specialization  to  host-imp  world 

We  refine  the  agent  node  into  host  and  imp.  We  refine  the  type  message  into  user-message, 
acknowledgement  (to  acknowledge  successful  receipt  of  an  item),  host-dead- 
acknowledgement  (to  acknowledge  receipt  of  an  item  at  the  imp  connected  to  the  destination  host 
when  that  host  is  currently  "dead",  and  host-going-down-message,  which  a  host  sends  its 
connected  imp  to  indicate  it  is  (voluntarily)  going  down.  Since  we  are  only  concerned  with  host 
communication  via  imps,  we  prohibit  CONNECT  holding  between  two  hosts. 

A  separate  agent  interface  defines  random  demons  to  describe  relevant  possible  behavior  of  the 
outside  world.  This  consists  of  two  demons, 

•  USER-SEND  to  create  a  user-message  with  destination  some  host  and  insert  it  into  the 
to-be-sent  attribute  of  a  host; 

•  USER-TURN-OFF-HOST  to  create  a  host-going-down- message  and  insert  it  into  the  to- 
be-sent  attribute  of  a  host  (this  models  the  voluntary  means  by  which  a  host  goes  down). 


« 
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Agent  host  inherits  the  definitions  of  agent  node.  In  addition,  it  also  has  the  following: 

*  attribute  connected- imp,  defined  as  the  (unique)  imp  to  which  the  host  is  CONNECTed 
(in  both  directions). 

•  pendina-demon  SEND  -  this  demon  is  triggered  by  insertion  of  a  new  item  into  the  host’s 
TO-BE-SENT  attribute.  Its  response  is  to  TRANSMIT  the  item  t,o  its  connected-imp  (in 
point  of  fact,  because  of  our  constraints,  the  connected  imp  is  the  only  node  to  which  the 
host  could  possibly  transmit  the  item). 


Agent  imp  inherits  the  definitions  of  agent  node  and  in  addition  has: 

•  Attribute  DEAD-HOSTS,  to  record  which  of  the  hosts  are  known  by  this  imp  to  be  currently 
"dead"  (dov;n  either  due  to  hardware  failure,  or  because  they  sent  a  host-going-down- 
message).  This  is  maintained  by  two  pending-demons: 

-  MARK-HOST-DEAD,  which  inserts  a  (connected)  host  into  the  imp's  dead-hosts 
when  that  host  has  become  inactive  or  a  host-going-down-message  has  been 
received  by  the  imp  from  that  host. 

-UNMARK-HOST-DEAD,  which  removes  a  host  from  the  imps  dead-hosts 
attribute  upon  successful  receipt  of  any  item  (other  than  one  with  a  host-going- 
dov.'n-message  as  its  message  attribute)  from  that  host  (successful  receipt  is 
observed  by  watching  for  insertion  of  an  item  into  the  pending  attribute). 

•  pending-demon  SEND  -  this  is  triggered  when  a  new  item  is  inserted  into  the  imp's  to-be- 
sent  attribute.  Its  response  is  to  first  remove  the  item  from  that  attribute;  then  it  tests  to 
see  whether  the  imp  is  connected  directly  to  the  destination  address  of  the  item  -i*  so, 
and  if  the  destination  is  a  host,  then  the  appropriate  acknowledgement  must  be  sent  and 
the  item  TRANSMITted  (depending  upon  whether  that  host  is  currently  regarded  as 
dead).  If  the  imp  is  not  connected  directly  to  the  item's  destination,  then  it  is 
TRANSMITTED  onv,iards  through  the  network  (in  this  specification  v^e  are  not  concerned 
with  selecting  which  node  in  the  network  is  the  most  appropriate  to  pass  the  item  on  to). 

•  pending-demon  RECEIVE  -  a  slight  specialization  of  the  RECEIVE  defined  for  nodes,  in 
that  the  response  v.aits  for  termination  of  the  TRANSMIT  gr  15  seconds  (a  "timeout"). 
As  before,  only  normal  completion  of  the  TRANSMIT  will  cause  insertion  of  the  item  into 
the  pending  attribute. 

•  pending-demon  PROCESS-M Y-MESSAGES,  to  discard  messages  addressed  to  this 
imp. 

•  action  ACKNOWLEDGE-OK,  used  to  create  an  acknowledgement  for  an  item, 
addressed  to  the  creator  of  that  item. 

•  action  ACKNOWLEDGE-DEAD,  similar  to  ACKNOWLEDGE-OK,  but  used  when  the 
destination  host  is  currently  dead. 

•  demon  CONNECTED-HOST-GONE-DOWN  •  this  is  triggered  when  a  connected  host  is 
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observed  to  have  become  inactive.  Its  response  is  to  invoke  action  DEADIFY,  to  discard 
all  items  addressed  to  that  host  at  present  in  the  imp’s  to-be-sent  attribute,  and  to 
unschedule  all  pending  SENDs  of  items  to  that  host. 

•  demon  TARDY-SEND-QUEUES  is  triggered  if  an  item  addressed  to  a  connected  host 
remains  on  the  to-be-sent  attribute  more  than  30  seconds.  Its  response  is  to  invoke 
DEADIFY. 


4.2.4  Implications  for  Gist 
We  required  the  following  refinements  of  Gist: 

•  agents,  which  have  independently  active  processes.  In  addition,  such  agents  may  be 
externally  activated  and  deactivated.  Deactivation  is  to  abort  the  currently  active  and 
triggered  processes  of  that  agent.  While  deactivated,  no  demons  of  that  agent  will  be 
triggered.  Upon  activating  a  previously  deactivated  demon,  action  ACTIVATE  is 
invoked.  None  of  the  history  prior  to  activation  is  available  to  that  agent.  Furthermore, 
agents  must  be  able  to  voluntarily  suspend  themselves  for  some  period  of  time  via  wait, 
during  which  time  none  of  their  demons  are  triggered.  Following  the  delay,  the  currently 
active  process  continues  from  the  point  after  the  wait. 

•  Real  time  -  "seconds"  for  wait  delays,  timeouts,  etc. 

•  pending  and  non-pending  demons.  Non-pending  demons  are  the  usual  Gist  demons, 
which  upon  triggering  are  invoked  immediately  (perhaps  interrupting  the  processing  of 
another  demon’s  response).  For  this  specification  we  required  another  class  of  demons, 
which  upon  triggering  would  add  themselves  to  the  end  of  an  implicit  queue  of  already 
triggered  demons.  Only  after  the  demons  earlier  on  the  queue  had  completed  their 
responses  would  such  a  demon  be  permitted  to  commence  processing  its  own  response. 
This  incorporation  of  a  weak  scheduling  mechanism  into  the  Gist  demons  was  thought 
appropriate,  rather  than  having  to  explicitly  build  a  scheduler.  We  did  some  explicit 
program-controlled  manipulation  of  the  pending  queue  when  some  of  the  pending 
demons  were  to  be  unscheduled. 


4.3  TEXT  FORMATTER  SPECIFICATION 


4.3.1  Source  of  Problem 

The  formatter  we  specify  is  designed  to  have  the  capabilities  of  the  formatter  described  by 
Kernighan  and  Plauger  in  chapter  5  of  their  book  [2]. 

We  give  a  (very)  brief  and  informal  account  of  the  facilities  the  text  formatter  is  to  provide. 

Input  to  the  formatter  is  a  sequence  of  lines,  where  lines  consist  of  sequences  of  characters.  Some 
lines  will  be  text,  some  will  be  commands  to  the  formatter.  Command  lines  are  identified  by  the 
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occurrence  of  a  in  the  first  column  followed  by  a  two  letter  abbreviation  of  the  name  of  the 
command. 

In  action  the  formatter  may  be  in  a  ''fill”  mode,  during  which  paragraphs  are  formed  by  packing  as 
many  input  words  as  possible  into  the  output  lines,  the  lines  being  "right-justified"  (to  produce  an 
aligned  right  margin,  like  this  paragraph)  by  padding  out  with  extra  spaces  between  words  if 
necessary.  When  not  in  "fill"  mode  the  input  text  lines  are  output  without  modification.  With  filling 
switched  off,  the  words  already  gathered  to  go  into  the  next  output  line  are  put  out  without  right 
.justification.  This  action  of  forcing  out  a  partially  collected  line  is  called  a  break.  Some  of  the 
commands  implicitly  cause  breaks  when  they  are  encountered,  even  though  they  may  not  cause 
filling  to  be  switched  off. 


We  present  the  commands  and  briefly  explain  their  actions: 

"filling"  commands 

fi  Cause  a  break  and  switch  on  "fill"  mode. 

nf  Switch  off  "fill"  mode. 

br  Cause  a  break  (but  does  not  switch  into  or  out  of  "fill"  mode) 

page  commands 

bp  n  Begin  page,  n  is  an  optional  numeric  argument,  which,  if  present,  is  taken  as  the 

number  of  the  new  page.  If  not  present  the  default  is  to  increment  the  current 
page  number  by  one.  Causes  a  break.  If  this  command  would  produce  an  entirely 
blank  page  (but  for  header  and  footer  titles),  i.e.  occurs  af  the  very  top  of  a  page,  it 
merely  adjusts  the  page  number  without  creating  the  blank  page. 

pi  n  Set  page  length  to  be  n  lines.  Default  is  n  =  66,  does  not  cause  break. 

he  t  Set  the  header  to  be  printed  at  top  of  each  page,  t  is  a  string  argument  which 

becomes  the  new  header.  The  character  "  J?  "  within  the  string  is  replaced  by  the 
current  page  number.  Does  not  cause  a  break. 

fo  t  Set  the  footer  title  to  be  printed  at  bottom  of  each  page.  Analogous  to  the  he 

command. 

Is  n  Set  line  spacing  to  n  (i.e.,  n  =  2  corresponds  to  double  spacing).  Default  is  n  =  1 , 

does  not  cause  a  break. 


sp  n 


Causes  a  break  and  produces  n  blank  lines.  Default  is  n  =  l.  Does  not  produce 
blank  lines  at  the  very  top  of  a  page. 
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ce  n 


ul  n 


Cause  a  break  and  center  the  ne)(t  n  text  lines  (i.e.,  insert  extra  spaces  if 
necessary  to  cause  the  text  lines  to  be  centered  within  the  current  margins.) 
Default  is  n  s  1 .  If  another  ce  command  is  encountered  whilst  centering  text  lines, 
the  new  command's  value  of  n  takes  precedence. 


Does  not  cause  a  break.  Default  is  n  =  1.  As  with  ce  command,  encountering 
another  ul  command  will  adjust  the  count  of  lines  to  be  underlined. 


rm  n  Set  right  margin  to  be  n.  Default  is  n  =  60,  does  not  cause  a  break. 

in  n  Set  left  margin  (indentation)  to  be  n.  Default  is  n  =  0,  does  not  cause  a  break. 

ti  n  Cause  a  break  and  set  the  left  margin  for  next  output  line  only  to  be  n.  Default  is 

n  =  0. 


Numeric  arguments  to  commands  may  be  preceded  by  a  "  "  or  in  which  case  the  value  is  taken 
to  be  the  current  value  of  the  parameter  being  set  incremented  or  decremented  accordingly.  An 
exception  to  this  is  the  ti  command  which  adjusts  relative  to  the  current  left  margin  setting. 


In  order  that  the  formatter  behave  reasonably  with  text  containing  a  minimum  of  formatting 
commands,  input  lines  which  start  with  blanks  or  are  entirely  blank  are  treated  as  follows:  Lines  empty 
but  for  blanks  cause  a  break  and  a  blank  line  to  be  output  (even  at  the  top  of  a  new  page).  Lines 
starting  with  n  blanks  (but  followed  by  other  characters)  where  n>0  cause  a  break  and  a  temporary 
indent  of  -i-  n. 


This  description  includes  many  interface  details  of  how  the  user  is  to  indicate  what  formatting 
activities  are  to  be  applied  to  what  portions  of  his  text;  we  shall  separate  the  specification  of 
formatting  activities  from  the  specification  of  how  to  direct  the  application  of  these  activities.  Our 
specification  is  concerned  with  the  former,  namely  the  tasks  of  formatting,  rather  than  the  interface 
details.  In  Section  4.3.3  we  briefly  consider  what  must  be  done  in  an  interface  to  our  specified 
portion, 


4.3.2  Formatter  activities 
Input  is  a  sequence  of 

•  "paragraphs"  •  each  consisting  of  a  sequence  of  "info«-words",  that  is  a  word  (sequence 
of  characters)  together  with  layout  information  (margins,  page«-size,  etc.).  The  words  are 
to  be  accumulated  into  right-justified  lines. 

•  "info*- lines"  -  a  line  (sequence  of  characters)  together  with  layout  information. 
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*  "padding*-lines"  •  these  are  to  emerge  as  blank  lines  in  the  output,  unless  they  would 

appear  at  the  very  top  of  a  page,  in  which  case  they  are  to  be  discarded. 

We  follow  the  convention  that  the  information  associated  with  the  first  word  to  go  into  a  line  sets 
the  characteristics  for  the  entire  line,  and  similarly  that  the  information  associated  with  the  first  line  to 
go  into  a  page  sets  the  characteristics  for  the  entire  page. 

Information  relevant  to  lines  consists  of:  left«-margin,  right*- margin,  line«-spacing  (the  number  of 
blank  lines  to  be  inserted  between  each  text  line)  and  subsequent*- left*- margin  (if  the  word/line  is  too 
long  to  fit  within  the  margins,  it  will  be  split  over  two  or  more  lines  -in  such  a  case  the  left  margin  of 
subsequent  lines  is  to  be  the  subsequent*- left*- margin). 

Information  relevant  to  pages  consists  of  header*-title,  footer*-title,  page*- length  and  begin*-pa9e. 
This  last  indicates  that  a  new  page  is  to  be  started.  In  the  original  input  we  do  not  permit  info*- words 
other  than  the  very  first  of  a  paragraph  to  cause  a  begin*- page. 

Output  is  a  sequence  of  sequence  of  lines  of  characters,  representing  the  page  images  produced 
as  a  result  of  the  formatting  operation. 

4.3.3  Interface 

The  input  as  described  by  Kernighan  and  Plauger  consists  of  a  sequence  of  lines,  with  conventions 
for  denoting  text  and  formatting  commands  within  this  sequence.  The  input  we  assume  pre-supposes 
some  interface  to  derive  from  the  user-input  (in  whatever  form)  the  paragraphs,  info*- lines  and 
padding*- lines  that  we  expect.  To  handle  Kernighan  and  Plauger 's  input  conventions  our  interface 
would  have  to 

•  recognize  and  decode  commands, 

•  extract  and  accumulate  words  (to  go  into  paragraphs)  from  text  lines: 

•  process  parameter  setting  commands  to  insert  the  appropriate  information  into  info*-lines' 
and  info*- words  (e.g.  a  command  to  set  the  right  margin  to  some  value  would  cause  that 
value  to  be  inserted  into  the  inform-'  "  of  info*-words/lines  following  that  command 
until  the  next  such  command); 


convert  space  dov.m  commands  into  the  appropriate  number  of  padding  lines. 
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4.3.4  Organization  of  specification 

FORMAT  is  the  top-leve'  action  invoked  to  do  the  formatting.  This  expects  a  sequence  of 
paragraphs,  info^lines  and  padding*- lines  which  compose  the  input  to  be  formatted. 


Formatting  is  divided  into  two  overall  stages  -first,  the  activities  to  form  individual  lines  of  output  are 
performed,  then  pages  are  formed  from  these  lines. 

•  FORMAT  initiates  the  processing  of  the  first  stage  by  creating  an  object  of  type 

mixlets*- input  to  which  the  input  sequence  is  attributed.  This  will  trigger  the  demons 
PARAGRAPHING,  SPLIT^-OVERLENGTH- LINES,  CENTERING, 

LEFT-MARGIN-PADDING  and  INTER-LINE-PADDING  to  go  to  work  on  the  input 
paragraphs  and  info-lines,  and  each  perform  their  activity.  Their  net  result  is  to  convert 
the  input  sequence  into  a  sequence  of  info- lines  and  padding- lines  (no  paragraphs  left) 
ready  to  be  incorporated  into  pages.  There  is  some  coordination  between  these  demons 
to  ensure  that:  overlength  lines  will  be  dealt  with  by  SPLIT-OVERLENGTH- LINES 
before  INTER- LINE- PADDING  and  LEFT- MARGIN-PADDING  act  on  them,  and 
CENTERING  is  performed  on  lines  before  LEFT-MARGIN-PADDING.  Otherwise  they 
act  independently. 

•  After  the  first  stage  of  formatting  we  are  left  with  a  sequence  of  info- lines  and  padding 
lines.  Prior  to  forming  pages,  FORMAT  converts  this  sequence  into  a  sequence  of 
simpler  objects,  which  we  call  "linelets";  Each  linelet  has  two  attributes,  information,  and 
either  a  line  (of  characters)  or  padding.  Action  PAGINATION  is  invoked  on  this  sequence 
to  produce  the  sequence  of  sequence  of  lines  representing  the  page  images. 


We  now  briefly  describe  the  activities  of  these  demons  and  actions; 

PARAGRAPHING  replaces  a  paragraph  (a  sequence  of  info-words)  by  a  corresponding  sequence 
of  (filled  and  right  justified)  info- lines.  This  is  achieved  by  selecting  a  partition  of  the  paragraph’s 
words,  and  for  each  element  of  the  partition  (i.e.,  a  sequence  of  words)  forming  an  info- line. 

•  If  the  line  is  to  represent  just  one  word,  no  justification  is  done. 

•  If  it  represents  two  or  more,  it  must  be  right  justified  (i.e.,  every  word  separated  by  at  least 
one  blank,  and  enough  blanks  inserted  to  align  the  leftmost  and  rightmost  words  with  the 
left  and  right  margins). 

The  only  acceptable  partitions  are  those  for  which  such  justification  of  the  necessary  lines  is  possible. 
Furthermore,  we  select  the  partition(s)  v/hich  minimize  the  total  number  of  info-lines  produced  (the 
essence  of  what  a  "filled"  paragraph  is). 


SPLIT-OVERLENGTH-LINES  ■  this  demon  splits  overlength  info-lines  (i.e.,  info-lines  for  which 
the  text  is  too  wide  to  fit  between  the  margins)  into  two  (or  more  if  necessary)  info- lines.  (Note  that 
this  also  will  take  effect  on  lines  produced  during  paragraphing,  so  excessively  long  words,  i.e.,  so 
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long  that  the  single  word  is  too  wide  to  fit  between  the  margins-each  of  which  will  have  been 
incorporated  into  a  separate  info<-line,  will  be  dealt  with  by  this  demon.) 

CENTERING  -  this  demon  adjusts  the  left  ♦■margin  value  of  those  info*- lines  which  are  to  be 
centered  in  order  to  center  their  text  between  the  margins. 

LEFT*- MARGIN^- PADDING  -  this  demon  inserts  the  appropriate  number  of  blanks  at  the  start  of 
each  text  line  which  has  a  non  zero  left*-margin  value. 

INTER*- LINE*- PADDING  -  this  demon  inserts  the  appropriate  number  of  padding  lines  after  each 
text  line  when  its  spacing  value  is  greater  than  zero. 

PAGINATION  ■  this  action  takes  the  sequence  of  linelets  and  forms  a  sequence  of  sequence  of 
lines,  the  output  page  images.  The  process  is  similar  to  that  applied  to  paragraphs;  the  incoming 
linelets  are  partitioned,  and  from  each  partition  a  page-image  is  constructed  (involving  discarding 
padding  lines  which  would  fall  at  the  top  of  a  page,  adding/discarding  padding  lines  at  the  bottom  as 
necessary  to  bring  the  total  page  size  to  the  appropriate  length,  including  page  header  and  footer  if 
required).  The  acceptable  partitions  are  those  for  which  such  construction  is  possible.  From  all 
acceptable  partitions,  we  select  the  one(s)  that  leads  to  the  I^Sfet  number  of  output  pages. 

4.3.5  Implications  for  Gist 

4.3.5. 1  New  Gist  usage 

The  primary  novel  use  of  Gist  in  this  specification  has  been  the  construct  continuations  gf 
<statement>  from  v.-hich  <object  €xpression>  satisfies  <predicate>.  This  was  applied  within  pagination 
and  paragraphing,  to  do  the  appropriate  activity  in  such  a  way  as  to  minimize  the  resulting  number  of 
pages/lines.  Hence  v/e  are  applying  a  minimization  predicate  over  all  possible  resulting  states  of  the 
execution  of  <statement>. 

Extensive  use  was  made  of  generator  expressions  to  denote  sequences  and  to  iterate  over 
sequences. 

4. 3. 5. 2  Exposed  weaknesses  of  Gist  and  dissatisfaction  with  specification 

On  many  occasions  within  this  specification  there  is  the  need  to  perform  some  action  which  creates 
some  new  objects  and  communicates  these  back  to  the  invoker-  the  invention  and  use  of  a  unique 
relation  for  the  sole  purpose  of  such  communication  is  a  clumsy  way  of  achieving  this.  Often  this  is 
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linked  with  the  use  of  iterative  constructs;  there  are  powerful  means  of  denoting  expressions,  and 
powerful  means  of  iterating  actions,  but  the  combination  of  the  two  is  not  available  (i.e.,  iterating 
actions  and  emerging  with  a  result). 

There  seems  to  be  a  large  overhead  in  creating  all  the  syntactic  support  for  relatively  trivial  actions, 
demons,  and  relations. 


Could  we  perhaps  have  gone  even  further  towards  a  descriptive  rather  than  algorithmic 
specification?  For  example,  the  seemingly  natural  decomposition  of  the  task  into  first  forming  lines 
and  then  combining  these  into  pages  might  be  regarded  as  an  unfortunate  split.  It  might  compromise 
our  ability  to  specify  behaviors  relying  on  the  detailed  interaction  of  these  stages  (e.g.,  padding  out  a 
filled  and  justified  paragraph  with  extra  blanks  to  make  the  overall  paragraph  length  longer  and  so 
avoid  "widows"  or  "orphans"  -when  the  last  line  of  a  paragraph  falls  on  the  top  of  a  new  page,  or  the 
first  line  of  a  paragraph  falls  at  the  bottom  of  a  page).  Is  there  some  suitable  structuring  of  the 
specification  that  would  not  be  biased  in  such  a  manner  and  yet  be  reasonably  divided  into 
comprehensible  components? 

4. 3. 5. 3  Advantages  accrued  from  the  use  of  Gist 
The  increased  ease  of  writing  a  specification  rather  than  an  algorithm  is  particularly  evident  in: 

•  The  use  of  the  continuations  gf...  construct  to  free  us  first  to  describe  a  general  means  of 
performing  some  activity  (e.g.,  forming  the  lines  to  represent  a  paragraph)  and  separately 
selecting  which  of  the  possibly  multiple  alternatives  are  appropriate  (e  g  ,  we  want  to 
minimize  the  resulting  number  of  lines  to  represent  that  paragraph).  Clearly  we  can 
always  write  a  "British  Museum"  style  algorithm  to  do  the  same,  but  Gist  allows  us  to 
specify  this  effect  with  ease. 

•  The  use  of  demons  to  direct  the  processing  activities  (e.g.,  centering,  paragraphing,  etc. 
are  demons  triggered  by  the  data  requiring  the  processing  these  demons  perform)  rather 
than  having  to  write  an  arbitrary  scheduler  ourselves. 


4.3.6  Extensions  to  formatter 

Kernighan  and  Plauger  suggest  several  possible  extensions  to  their  formatter’s  capabilities.  Some 
of  their  extensions  fall  entirely  within  the  portion  we  have  chosen  to  regard  as  interface.  We  will  limit 
our  attention  to  those  affecting  the  formatting  activity  itself.  We  consider  how  we  might  incorporate 
these  extensions  into  our  specification  (which  was  ogl  designed  with  these  extensions  in  mind). 
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4.3.6. 1  Separating  justification  and  filling 

We  consider  switching  justification  on  and  off  separate  from  filling.  A  little  consideration  suggests 
that  justification  is  meaningless  outside  of  the  context  of  paragraphs;  hence  we  may  limit  our 
attention  to  the  paragraphing  activity. 

We  make  use  of  a  new  relation  TO<- BE JUSTIFIED,  which  holds  of  words  in  paragraphs  whose 
lines  a'e  to  be  justified.  As  before,  we  presuppose  that  the  interface  has  inserted  this  relation  on  the 
appropriate  words. 

Action  CREATE«-JUSTIFIED<-INFO*-LINES<-FOR«-PARAGRAPH  requires  modification  to  examine 
each  sequence  of  words  to  go  into  a  line  and  use  CREATE«-JUSTIFlED<-INFO«-LINE«- FOR*- WORDS 
or  CREATE*-UNJUSTIFIED<-INFO*-LINE«-FOR*-WORDS  as  appropriate  (and  following  such 
modification  might  be  better  named  CREATE*- INFO*- LINES*- FOR*- PARAGRAPH). 

4. 3. 6. 2  Filtering  output  pages 

This  extension  allows  us  to  limit  our  interest  to  a  subset  of  the  output  pages.  This  may  be  easily 
incorporated  by  a  modification  to  CREATE*-PAGE«- IMAGE,  causing  the  empty  sequence  of  lines  to 
be  "returned"  if  th  ^  page  number  is  not  among  those  in  which  we  are  interested. 

4. 3. 6. 3  Forcing  text  to  appear  on  a  single  page 

This  extension  is  to  permit  us  to  force  portions  of  the  text  to  occur  entirely  in  one  page.  To 
incorporate  this  extension,  we  must  extend  the  datatype  information  to  have  an  extra  attribute,  a 
"group";  the  intended  behavior  is  that  all  info*-lines  and  info*- words  that  are  related  to  the  same 
"group"  must  appear  within  the  same  page.  In  the  formation  of  paragraph  lines  from  words  we  must 
take  care  to  ensure  that  the  set  of  groups  to  which  it  related  is  the  union  of  the  groups  to  which  its 
constituent  words  are  related.  The  group  information  will  be  used  by  relation  PAGE*- PARTITION  to 
require  that  info*- lines  related  to  the  same  group  to  fall  within  the  same  element  of  the  partition. 

4. 3. 6. 4  Extra  space  after  sentence 

The  purpose  of  this  extension  is  to  cause  more  than  one  space  to  follow  the  end  of  a  sentence  if  it 
falls  v.'ithin  the  interior  of  a  line.  We  may  assume  that  this  is  applicable  only  during  paragraph 
formation.  The  effect  could  be  achieved  by  first  defining  an  end-of  sentence  recognizer;  then  within 
ARBITRARlLY*-PAD*-WORDS*-WlTH*-BLANKS  we  may  examine  all  words  except  for  the  very  last 
one  to  go  on  the  line  and,  if  it  is  recognized  as  a  sentence  terminator,  require  that  it  be  followed  by  at 
least  two  blanks 
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4. 3.6. 5  Hyphenation  during  filling 

We  will  not  consider  the  task  of  determining  suitable  hyphenation  points  of  words;  if  we  were 
somehow  able  to  make  such  a  determination  we  could  use  the  information  2is  follows: 

Within  CREATE<-JUSTIFIED*-INFO«- LINES*- FOR«- PARAGRAPH  we  would  extend  the  partitioning  to 
include  not  only  all  possible  partitions  of  (undivided)  words  but  also  partitions  in  which  a  single  word 
could  be  split  (according  to  our  legal  hyphenation  scheme}  over  the  end  of  one  partition  element  and 
onto  the  start  of  the  next.  The  characters  of  the  first  portion  of  the  split  word  would  be  appended  with 
the  hyphenation  character  ("-"),  and  go  to  form  the  last  info*-word  of  the  first  partition  element,  the 
remaining  characters  going  into  an  info*-word  at  the  start  of  the  next  partition  element  (with  the 
possibility  of  further  hyphenation,  which  might  be  necessary  if  this  is  a  verrrrry  long  word...). 

For  example,  here  are  some  words  to  be  partitioned  for  paragraphing. 

Here  are  some 
words  to  be  partit¬ 
ioned  for  para¬ 
graphing. 

4. 3. 6. 6  Conditionals 

This  class  of  extensions  is  to  permit  the  formatting  actions  to  be  dependent  on  the  formatting 
conditions.  This  is  the  least  specific  of  the  extensions,  and  we  can  only  speculate  as  to  how 
amenable  our  specification  might  be  to  catering  for  whatever  power  might  be  desired. 

We  anticipate  that  our  specification  style  would  permit  such  features  to  be  incorporated  in  a 
reasonably  straightforward  manner--we  may  specify  the  alternative  actions  as  a  non-deterministic 
choice  at  the  appropriate  place  for  ,the  definition  of  such  actions,  and  make  the  selection  at  the 
appropriate  place  for  the  testing  of  the  conditions. 


5-1 


5.  GIST  INITIAL  OPERATING  CAPABILITY 
DESCRIPTION 

5.1  INTRODUCTION 

The  Gist  Initial  O,  ^rating  Capability  (IOC)  is  the  first  step  toward  a  package  of  tools  to  help 
specifiers  create,  test  and  rnaintain  Gist  specifications.  The  IOC  provides  the  following  facilities: 

•  A  Gist  editor  which  enables  the  specifier  to  interactively  create  and  modify  the  source  text 
of  Gist  specifications  The  editor  ensures  that  the  specificatiorrTs  syntactically  correct  at 
all  times 

•  A  pretty  printer  which  formats  the  text  of  a  specification  for  enhanced  legibility. 

•  A  Gist  evaluator  capable  of  executing  Gist  expressions,  predicates,  and  statements. 

•  A  Gist  executive  which  operates  in  the  context  of  a  "current"  specification.  The 
executive  permits  the  specifier  to  create  an  initial  execution  state,  specified  in  Gist,  and 
interact  with  the  evaluator  to  explore  possible  activity  from  that  state. 

•  The  ability  to  save  Gist  specifications  created  in  the  ICX^  environment  on  files,  and  to  load 
such  saved  specifications  into  the  ICXI. 

The  structure  of  the  ICX  is  depicted  in  Figure  5-1.  The  entire  IOC  is  implemented  in  Interlisp  [3]  and 
runs  within  the  standard  Interlisp  environment.  The  user  communicates  through  the  Gist  executive  to 
the  various  Gist  tools,  and  need  not  interact  with  or  understand  Interlisp  at  all.  However,  any 
command  not  specifically  recognized  as  meaningful  to  one  of  the  tools  is  treated  as  an  Interlisp 
command  This  means  that  the  user  has  available  the  full  facilities  of  Interlisp,  including  the 
Programmer's  Assistant  facilities.  It  also  means  that  eri^r  messages  in  response  to  illegal  inputs  may 
appear  obscure  to  users  unfamiliar  with  Interlisp. 

The  editor  and  prettyprinter  subsystems  are  constructed  automatically  (as  Interlisp  programs)  by 
another  program,  called  POPART,  from  a  BNF  syntax  for  Gist.  These  tools  provide  all  access  to  the 
specification,  both  in  its  internal  tree  representation  and  its  external  text  representation.  The 
specification  is  tested  by  the  Gist  evaluator  which  is  composed  of  a  declaration  compiler  and  an 
interpreter.  The  evaluator,  through  the  interpreter,  produces  the  behavior  of  the  specification  on  the 
test  data.  The  evaluator  uses  APS,  a  programming  language  embedded  in  Interlisp,  to  maintain  an 
internal  representation  of  one  or  more  chains  of  process  states  as  the  specifier  tests  his  specification. 
Finally,  the  Gist  executive  interfaces  the  specifier  to  these  tools. 
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Figure  S- 1 :  Gist  IOC  configuration 
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5.1.1  Transliteration 

(n  much  of  the  printed  documentation  on  Gist,  including  examples  of  Gist  specifications,  symbols 
are  used  which  are  not  available  in  the  standard  ASCII  character  set.  The  IOC  requires  that  these 
symbols  be  transliterated  as  shown  in  Table  5-1. 

Table  5-  i  ;  IOC  symbol  transliteration 
Publication  Symbol  IOC  transliteration 

and 
or 
xor 

implies 
equiv 
not ,  ~ 
for  all,  all 

there  exists,  exists 
element  of 
union 
intersect 

5.2  Editor,  PrettyPrinter,  and  File  I/O 

The  Gist  editor,  parser,  and  prettyprinter  are  produced  automatically  from  a  BNF  definition  of  Gist's 
syntax  by  a  program  named  POPART.  The  full  complement  of  commands  and  capabilities  afforded 
by  the  resulting  tools  is  documented  in  [5].  A  subset  of  these  commands,  sufficient  for  convenient 
creatiori  and  editing  of  Gist  specifications,  is  documented  below.  Each  command  has  a  short  name, 
mnemonic  for  the  function  it  performs.  Some  commands  also  require  an  operand.  A  command  is 
invoked  s'mpiy  by  typing  its  name  (and  operand)  in  response  to  the  prompt  from  the  IOC 
executive.  (Each  prompt  is  preceded  by  a  number,  which  can  be  used  in  Programmer's  Assistant 
commands  to  refer  to  the  corresponding  IOC  event.)  If  the  command  needs  no  operand,  its  name 
should  be  followed  immediately  by  a  carriage  return,  without  intervening  spaces.  If  the  command 
needs  an  operand  v/hich  is  not  Gist  text,  the  command  name  should  be  followed  by  a  space,  and  then 
by  the  operand  and  a  terminating  carriage  return.  If  the  operand  is  Gist  text,  the  command  should  be 
followed  by  a  carriage  return,  then  the  Gist  text  (vrhich  may  be  spread  across  as  many  lines  if 
convenient)  terminated  by  two  periods  and  a  carriage  return. 

The  editor  maintains  at  all  times  a  specification  being  edited  and  a  current  focus  (syntactic 
constituent)  within  that  specification  Initially,  both  are  empty.  The  editing  commands  will  be 
described  in  two  groups: 
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•  commands  which  alter  the  specification 

•  commands  which  change  the  editor’s  focus  within  the  specification 

5.2.1  Commands  which  Alter  Specification  Text 
*^Set 

Gist  text  .. 

The  Set  command  requires  a  single  operand,  a  Gist  text  string.  That  text  becomes  the  current 
specification  and  the  current  focus. 

'^Replace 
Gist  text  . . 

The  Replace  command  requires  a  single  operand,  a  Gist  text  string.  That  text  replaces  the  current 
focus  within  the  specification,  and  becomes  the  new  focus. 

The  Replace  command  is  also  used  to  embed  existing  text  in  larger  text.  This  is  done  by  using  the 
special  string  "$$"  to  refer  to  the  existing  text  within  the  embedding  text.  For  instance,  to  replace  the 
Gist  text  "ship:captain“  with  "ship:captain;salary"  either  of  the  following  commands  would  suffice: 

^-Replace 

ship : captai n : sal  ary  . . 

*-Replace 
S$:sa1ary  .. 

^ReplaceAll 

Gist  text  ..  ==>  Gist  text  .. 

The  ReplaceAll  command  replaces  every  occurrence  of  the  first  text  fragment,  which  appears  as  a 
syntactic  constituent  of  the  current  focus,  with  the  second  text  fragment.  The  current  focus  is  not 
changed.  This  command  is  most  useful  for  changing  some  identifier  name  in  a  specification. 

•-After 

Gist  text  . . 

'i-e  After  command  adds  its  operand  after  the  current  focus.  The  current  focus  must  be  an 
.  e-.-  0*  an  "iterated  field"  in  the  grammar.  In  Gist,  this  means  a  statement  or  declaration  within  a 

■  .I  'o'e  specification  within  the  list  of  roles  of  an  action  or  relation  declaration,  etc.  In  general,  if 

•  jen!  being  added  is  the  same  "kind"  of  thing  as  the  current  focus  constituent,  the  After 

•  s  o'ctabiy  allowed  So,  for  example,  a  type  declaration  can  be  added  after  any  other 

.  After  command  If,  on  the  other  hand,  the  current  focus  combines  syntactically 
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with  the  new  text  to  form  a  new  constituent  of  the  same  "kind"  as  the  current  focus,  the  Replace 
command  should  be  used.  So,  to  change  a  specification  which  read  "officer:salary"  to  read 
"officerisalary  *  1.1"  the  Replace  command,  rather  than  the  After  command,  is  appropriate.  The 
After  command  does  not  change  the  current  focus. 

^-Before 
Gist  text  . . 

The  Before  command  is  like  the  After  commanc,  but  places  the  new  text  immediately  before  the 
current  focus,  within  an  iterated  field. 

•►Delete 

The  Delete  command  deletes  the  current  focus,  which  must  be  an  element  of  an  iterated  field  or  an 
optional  element.  Vk'hen  deleting  an  element  of  an  iterated  field  other  than  the  final  element,  the 
separator  following  the  element  is  also  deieted.  For  instance,  deleting  a  statement  in  a  block  will 
delete  the  following  it  as  well. 

No  change  to  a  specification  is  ever  permitted  if  that  change  would  result  in  a  syntactically 
incorrect  specification.  An  attempt  to  make  such  a  change  v,'ill  produce  an  error  message  indicating 
a  point  in  the  text  beyond  which  no  attempted  parse  could  progress.  The  specification  and  current 
focus  are  left  unchanged  by  the  attempt. 

5.2.2  Commands  which  Change  the  Editor’s  Focus 
►Find 

Gist  Text . . 

The  text  must  be  a  complete  syntactic  constituent.  Thus  "salary"  and  "salary  •  1000"  a'e 
acceptable,  but  "salary  ■"  is  not.  The  Find  command  looks  for  an  identical  constituent  within  or 
beyond  the  current  focus.  The  first  one  found  becomes  the  new  focus  If  none  is  found,  the  focus  is 
not  changed. 

►Top 

The  Top  command  changes  the  current  focus  to  be  the  entire  specification. 

►fn 

If  the  current  focus  is  an  "iterated  field"  e  g.,  the  statements  of  a  block,  the  In  command  resets  the 
focus  to  the  first  element  of  the  iterated  field  Otherwise,  the  current  focus  is  set  to  some  immediate 
subexpression  of  the  focus. 
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«-Out 

The  Out  command  resets  the  focus  to  its  immediate  parent  constituent. 

Next  integer 

If  the  curreni  focus  is  an  element  of  an  iterated  field,  the  Next  command  can  be  used  to  change  the 
focus  to  another  element  of  the  field.  The  desired  element  is  designated  by  an  integer  operand.  The 

positive  integers  designate  has  current  focus  as  1  and  its  successors  as  2,3 .  The  negative  integers 

designate  the  elements  from  the  last  (-1 )  back  to  the  first.  If  the  operand  is  omitted,  the  focus  is  reset 
to  its  immediate  successor  in  the  iterated  field. 

♦-Previous 

If  the  current  focus  is  an  element  of  a  iterated  field,  Previous  resets  the  focus  to  its  predecessor  in 
that  field. 

5.2.3  PrettyPrinting 

The  command  Pretty  may  be  used  at  any  time  to  display  a  formatted  version  of  the  current  editor 
focus.  The  Gist  prettyprinter  automatically  breaks  the  text  into  lines,  inserting  spacing  and 
indentation  appropriately  to  enhance  readability  of  the  text.  Examples  of  the  format  produced  may  be 
seen  in  Sections  6.1  and  6.2. 

5.2.4  Commands  for  Saving  and  Restoring  Specifications 
♦-Read  < f  i  1  ename> 

The  Read  command  expects  a  single  parameter,  a  Tops-20  filename.  Read  restores  the 
specification  saved  on  the  named  file.  The  specification  and  current  focus  in  effect  are  both  replaced 
by  the  specification  read  from  the  file.  This  file  should  be  one  created  by  the  Write  command.  The 
Read  command  is  equivalent  to  using  the  editor’s  Set  command  and  retyping  the  specification. 

♦-Write  <f i  1  ename> 


Write  makes  a  prettyprinted  copy  of  the  current  specification  on  the  named  file. 
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5.3  Specification  Tes^  'ing 

In  order  to  test  a  specification,  the  specifier  must  have 

•  a  Gist  specification 

•  an  "initial  state"  from  which  testing  is  carried  out 

•  some  behavior  to  be  tested 

A  Gist  specification  consists  of  a  block  of  declarations,  bracketed  by  begin  and  end.  The  IOC 
expects  these  declarations  to  be  augmented  by  one  or  more  Gist  statements  placed,  by  convention,  in 
this  outermost  block  of  the  specification  following  the  declarations  It  is  the  function  of  these 
statements  to  establish  an  initial  state  from  which  testing  is  carried  out.  The  actual  test  behavior  is 
then  run  by  interaction  with  the  Gist  evaluator,  which  consists  of  interdependent  compiler  and 
interpreter  portions. 

5.3.1  The  Gist  Declaration  Compiler 

In  order  to  permit  the  declarations  (of  types,  relations,  etc.)  to  affect  the  evaluation  of  the 
commands  used  to  test  the  specification,  the  ICX  performs  a  compilation  of  the  declarations 
appearing  in  the  specification.  This  compilation  process  is  initiated  by  the  command  gist: 

«-gist 

In  response  to  this  command,  the  IOC  compiles  the  declarations  and  places  the  user  in  an 
environment  for  interaction  with  the  Gist  evaluator.  In  this  environment,  interactions  are  prompted  by 
the  symbol  and  numbered  in  a  sequence  independent  from  the  numbering  of  interactions  with 
the  editor  To  resume  ed'tmg  operations,  the  user  should  type  "OK"  in  response  to  the  "■>"  prompt. 

5.3.2  The  Gist  Evaluator 

The  IOC  permits  the  user  to  provide  Gist  statements,  predicates,  and  expressions  interactively  for 
evaluation  'elative  to  the  "current  process  state".  An  initial  state  is  established  by  the  init  command. 


->init 

This  command  causes  the  evaluator  to  execute  all  statements  in  the  specification's  outermost  block. 
These  statements  are  executed  sequentially  in  order  of  appearance,  and  without  the  semantic  effects 
of  any  constraints  in  the  specification,  (including  type  requirements).  It  is  currently  the  user's 
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responsibility  to  ensure  that  the  resulting  state  is  a  valid  one.’®  Typically,  the  initial  state  is 
established  by  means  of  a  single  atomic  statement,  which  creates  an  adequate  process  environment 
for  the  desired  testing. 


Interactive  testing  relative  to  the  current  state  is  ordered  by  the  command: 
object  expression,  predicate,  or  statement  .. 

The  text  of  the  Gist  constituent  to  be  evaluated  may  extend  across  several  lines  of  terminal  input.  The 
final  line  must  terminate  with  Provided  the  input  parses  as  one  of  the  three  syntactic  classes 
indicated,  it  is  processed,  according  to  its  syntactic  class,  as  follows: 

•  Object  expressions  are  evaluated  relative  to  the  current  state.  If  the  expression  has  no 
referent,  "Failed..."  will  be  printed.  Otherwise,  some  referent  of  the  expression  will  be 
displayed.  The  current  process  state  does  not  change. 

•  Predicates  are  also  evaluated  relative  to  the  current  state.  The  predicate's  value,  TRUE 
or  FALSE,  is  displayed.  If  the  value  is  TRUE,  and  the  predicate  has  leading  existentially 
quantified  variables,  a  set  of  bindings  for  those  variables  is  also  displayed.  Conversely,  if 
the  value  is  FALSE  and  the  predicate  has  leading  universally  quantified  variables,  a  set  of 
bindings  for  these  variables  is  displayed.  The  current  process  state  does  not  change. 

•  Statements  are  executed  from  the  current  state.  If  the  statement  has  any  valid  executions 
some  valid  execution  is  carried  out,  and  "success"  is  displayed.  The  final  state  of  this 
execution  becomes  the  current  process  state,  and  is  linked  via  the  states  traversed  in 
attaining  it  back  to  the  previous  current  state.  Otherwise  "Failed..."  is  printed  and  the 
current  state  remains  unchanged.  In  this  case  the  IOC  command  "why" 

->  why 

will  provide  some  indication  of  a  reason  for  failure  of  the  statement.’® 

The  Gist  constituent  to  be  evaluated  by  the  command  may  make  use  of  any  types,  relations, 
attributes,  and  actions  defined  in  the  user's  current  specification. 


Since  a  Gist  process  state  is  independent  of  variable  names,  each  interaction  takes  place  in  a  bare 
variable  environment  ■  variables  may  not  be  used  freely  in  these  inputs.  They  may  of  course  establish 
their  own  internal  binding  environments. 


’^Gist's  semantics  define  legitimate  transitions  from  valid  states  to  new  valid  states.  Until  an  initial  valid  state  is  established, 
the  constraints  cannot  be  enforced. 

’®This  reason  is  a  constraint  violated  along  the  "longest”  partial  execution  path,  as  measured  by  a  heuristic  distance  metric. 
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5.3.3  Literal  and  Created  Objects 

Integer  and  character  sequence  Constants  may  be  included  in  specifications  and  IOC  interactions 
by  use  of  Interlisp  integer  and  string  constants/*^  Constants  of  other  base  types  are  included  by 
using  as  an  expression  an  identifier  whose  name  does  not  contain  a  and  which  is  not  used  as  a 
variable  name  in  the  lexical  context  in  which  it  appears.  All  such  uses  of  a  given  identifier  refer  to 
some  object,  having  that  identifier  as  its  "internal"  name.  All  other  objects  are  created  by  the 
execution  of  a  Gist  create  statement,  and  are  given  internal  names  consisting  of  the  first  few 
characters  of  the  objects  type  and  several  digits.'® 

5.3.4  Input/Output  Facilities 

Although  there  are  no  defined  I/O  activities  in  Gist,  the  IOC  provides  a  few  basic  facilities  for 
testing  interactive  pa'is  of  specifications. 

Terminal  input  to  a  process  may  be  provided  by  the  pseudo  expression  GISTREAD.  GISTREAD 
(prompt  string)  may  appear  as  an  object  expression  anywhere  in  a  specification.  The  evaluator  will 
process  this  expression  by  printing  the  referent  of  prompt-string,  which  may  be  any  Gist  object 
expression  but  is  typically  a  string  constant.  The  evaluator  will  then  read  a  single  Gist  object 
expression  (typically  a  literal)  from  the  terminal  and  its  referent  becomes  the  referent  of  the 
GISTREAD  expression.'® 

Terminal  output  is  provided  by  the  pseudo  action  GISTPRINT.  GISTPRINT (object  expression)  may 
appear  as  a  statement  anywhere  in  a  specification.  The  referent  of  the  object  expression  is  output  to 
the  terminal.  The  output  consists  of  the  internal  name  of  the  object  expression’s  referent,  together 
with  its  "boundary"  as  specified  in  any  boundary  declaration  for  the  referent  s  type.  The  Gist  syntax 
for  boundary  declarations  is  extended  in  the  IOC  to  permit  specification  of  a  print  boundary.  For 
example,  the  declaration; 

bound  employee  for  print  bv  isalary,  ::supervisor 

v^ould  cause  GISTPRINT,  when  printing  an  object  of  type  employee,  to  print  not  only  the  object  s 
internal  name  but  to  display  its  salary  and  all  other  objects  having  it  as  their  supervisor.  In  displaying 


'^Real  numbers  are  not  currently  supported  by  the  IOC. 

18 

The  IOC  test  for  object  identity  is  based  on  these  internal  names.  For  this  reason,  literals  should  NOT  be  given  names 
consisting  of  characters  followed  by  digits 

1d 

GISTREAD  may  be  considered  to  be  a  facility  which  allows  the  user  to  simulate  an  unspecHied  portion  ol  a  system. 
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the  boundarv,  the  values  are  themselves  printed  according  to  any  print  boundaries  declared  for  their 
types.  This  recursive  printing  of  boundaries  is  cut  off  at  a  depth  controlled  by  the  user.  The  IOC 
command 

->  GISTPRINTDEPTH  [integer] 

resets  the  cutoff  depth  to  the  given  integer.  A  depth  of  0  indicates  printing  of  an  object's  internal 
name  only.  Depth  N  indicates  printing  an  object’s  internal  name,  together  with  printing  its  print 
boundary  to  a  depth  of  N-1,  The  initial  depth  setting  is  0. 

Since  all  terminal  I/O,  whether  direct  commands  to  the  IOC  or  GISTREAD  or  GISTPRINT 
interactions,  is  performed  through  Interlisp,  transcripts  of  sessions  may  be  made  with  Interlisp’s 
DRIBBLE  facility.  Terminal  characteristics,  such  as  linelength,  may  be  established  by  the 
conventional  Interlisp  mechanisms. 

5.4  Debugging/Testing  Aids 

A  primitive  form  of  debugging  can  be  obtained  by  interspersing  GISTPRINT  statements  at  strategic 
points  in  a  specification.  Another  facility  is  the  ability  to  "trace"  or  "break"  certain  activity. 

Tracing  consists  of  printing  information  on  the  terminal  in  response  to  various  state  changes. 
Breaking  is  similar  to  tracing,  but  also  provides  a  pause  in  execution  during  which  the  user  may 
interact  with  the  IOC.  In  particular,  he  may  evaluate  predicates  and  expressions  relative  to  the 
statement  at  which  the  break  occurs.  When  satisfied,  he  gives  an  "OK"  command  and  processing 
continues. 

Tracing  and  breaking  are  turned  on  by  the  IOC  commands  GTRACE  and  GBREAK; 

->GTRACE  [narne^ . name^] 

->6BREAK  [namej . name^] 

where  each  name^  may  be: 

•  An  action  name,  in  which  case  invocations  of  the  action  are  traced /broken.  The  action 
name,  together  with  the  names  of  its  formal  parameters  and  corresponding  actual 
parameters  are  printed. 

•  A  relation  name,  in  which  case  every  insertion  or  deletion  of  a  relationship  in  the  relation 
is  traced/broken. 

*  An  attribute  name,  in  which  case  each  change  involving  that  attribute  is  traced/broken. 

*  A  type  name,  in  which  case  classification  and  de-classification  of  objects  in  the  type  is 
traced/broken  (including  creation  and  destruction  of  objects  in  the  type). 

i 
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The  command  forms: 

->GTRACE  [T] 

->GBREAK  [T] 

can  be  used  to  trace/break  all  activity  which  may  be  traced /broken. 

Tne  user  must  be  aware  that  in  evaluating  a  statement,  the  evaluator  is  conducting  a  search  for  a 
valid  execution.  Tracing  and  breaking  takes  place  as  the  search  progresses.  Some  of  the  broken  or 
traced  activity  may  be  taking  place  along  paths  of  the  search  which  will  be  abandoned,  not  leading  to 
valid  executions. 

T racing/breaking  may  be  turned  off  selectively  by  the  commands: 

->GUNTRACE  [namej . name^^] 

->GUNBREAK  [namej,  ....  name||] 

T  can  be  used  as  an  operand  to  these  commands  to  turn  off  all  enabled  tracing/breaking,  regardless 
of  whether  it  was  enabled  with  the  "T"  operand. 

5.4.1  Modifying  a  Specification 

After  creating  and  testing  a  specification,  the  user  will  likely  want  to  make  changes  to  it.  This  is 
done  by  exiting  the  Gist  evaluator  (via  the  "OK"  command)  and  giving  the  editor  commands 
necessary  to  make  the  desired  change.  Most  changes  to  the  specification  will  require  re  analysis  of 
part(s)  of  the  specification  for  the  changes  to  affect  further  testing.  Currently  this  is  only  possible  by 
reentering  the  Gist  evaluator  (via  the  "gist"  command)  and  beginning  further  testing  with  the  "init" 
command,  which  re  establishes  the  "initial"  state  as  the  "current"  state. 

5.5  IOC  Coverage 

Gist  is  still  undergoing  frequent  change,  both  to  the  syntax  of  established  language  constructs  and 
by  additions  to  the  language.  Appendix  I  contains  the  Gist  grammar  used  by  the  IOC  as  of  October, 
1980.  This  is  a  context  free  grammar  in  the  notation  used  by  the  POPART  system.  The  Gist  editor 
may  be  used  to  create  any  specification  which  is  a  "statement"  in  this  grammar. 

The  IOC  evaluator  is  not  capable  of  evaluating  this  full  range  of  specifications.  Among  the 
important  Gist  concepts  not  covered  by  the  evaluator  are: 

•  temporal  reference  (with  a  few  minor  exceptions) 

’  sets  and  sequences  (multivalued  attributes  are  handled,  however) 
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•  orderings  (except  for  the  ordering  of  integers) 

•  generators 

•  demons 

•  pseudo-parallelism 

In  Gist,  literal  objects  are  normally  introduced  in  the  declarations  of  their  types.  The  IOC 
declaration  compiler  does  not  yet  process  these  declarations.  It  is  therefore  necessary  to  establish 
the  type  of  any  non-numeric  literals  used  in  the  specification  by  means  of  the  statement(s)  setting  up 
the  initial  state.  This  is  accomplished  by  the  inclusion  of  statements  of  the  form:  _  ^ 

insert  literal  isa  type 


6-1 


6.  IOC  TRACES 


6.1  IOC  TRACE-PSL  EXAMPLE 

Below  is  a  trace  of  a  user  interactir>g  with  the  ICX:  to  explore  behavior  of  a  simplified  specification 
of  the  Program  Support  Library. 

SB-Read  PSL.GST 

89-Pretty 

begin 

type  project(any  1 ibrary : :unique) ; 
type  1ibrary(any  f i 1 e unique) ; 
type  fi1e(any  unit:  :unique) ; 
type  unit(any  un i t-contents : 1 i ne )bound  destroy 
by  equiv;unit-contents; 

type  1ine(any  chars  :  characte r .  any  indudes-un  it :  uni t ) ; 
type  character; 

relation 

UNIT-INCLUOES( i nc 1 udor : un i t . included: unit) 
def inition 

there  exists  1 ine | includor: un it-contents=l ine  and 
( 1 ine : incl udes-unit= included  or 
UNIT-INCLUDES( 1 ine: includes-unit, included)): 

always  prohibited  CIRCULAR-INCLUSION  there  exists  unit) 
UNIT-INCLUDES(unit,unit); 

type  update-command(current-f i 1 e : f ile , any  update-sub-commands: 

update-sub-command); 

type  update-sub-command(optional  current-un i t : un i t ) 
supertype  of <add-command : 

purge-command : 
change-command) ; 

type  add-command{ any  add-data : 1  i ne ) ; 
type  purge-command; 

type  change-command ( any  change- sub-commands : change- sub -command) ; 
type  change-sub-command  supertype  of<insert-command; 

modify-command; 

delete-command); 

type  insert-command{any  insert-data:! ine) ; 

type  modify- command (optional  1 ine-to-mod :line,oldchar:character, 

newchar: character) ; 

type  delete-command( any  1 ine-to-del :  1 ine) ; 


6-2 


IOC  TRACES 


action 

UPDATE [update -command] Vet  f ne  =  update-command : cur rent- file , 
up -com: update- sub -command -up date -command ; up date -sub- commands 
def i nition 

case  up-com  of  add-command 
=>ADD[f lie. up-com]; 
purge-command 

=> PURGE [up -com ;cur rent- unit]; 
change-command 

*>CHANGE[up-com: current-un it , up-com] ; 
end  case; 

action 

ADD[f ile, add- command] 
def inition 

atomic  create  unit.l; 

insert  all  un it . 1 : uni t-contents=add-command; add-data ; 
insert  fi 1e : unit=unit .  1 
end  atomic; 

action 

PURGE[unit] 

precondition  not  there  exists  including-unit:uhit, 

J ine I including-unit ; unit-contents® 1 ine 
and  1 ine : i nc1udes-unit=uni t 
definition 
destroy  unit; 

action 

CHANGE [ un i t , change-command]! et  ch-com: change -sub -command® 
change -command : change- sub- commands 
def inition 

case  ch-com  of  insert-command 
=>INSERT[unit, ch-com]; 
modify-command 

=>MODIFY[unit , ch-com] ; 
delete-command 

=>DELETE[unit, ch-com] ; 
end  case; 

action 

INSERT[un it, in  sent- command] 
def inition 

insert  all  un i t : un i t-contents= insert-command : i nsert-data ; 
action 

DELETE[unit, delete -command] 
definition 

delete  all  un i t : unit-contents=delete-command; 1 ine-to-del : 
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action 

MODI FY[ uni t .modify- command] let  ol debar : character«mod if y-command 
ol debar , newchar: character^modify-command : newchar 
def inition 

if  there  exists  1 ine (modify-command: 1 ine-to-mod=l ine 
then  DO-MODIF Y[ 1 ine ,un it .oldchar, newchar] 
else  DO-MODIFY[(a  1 ine |D0-M0DIFY(1 ine, unit. 

S,S)asof  ever), 
unit ,ol debar, newchir]; 


action 

DO-MODI FY[1 ine, unit, character. 1 .characte r .  2] 
precondition  line=unit: unit-contents 
def inition 

if  1 ine : cha rs  =  character ,  1 
then  begin 

delete  1 i ne ; chars=character . 1 ; 
insert  1  ine : chars  =  character.2 
end ; 


atomic 


insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 


myproject  isa  project; 
mylibrary  isa  library; 
my file  isa  file; 
myproject; 1 ibrary=myl ibrary ; 
myl ibrary ; f ile=myf ile; 


chara 
charb 
chare 
chard 
chare 
chart 
un  ita 
myf  i  1  e 
un  itb 
myf i  le 


isa  character; 
isa  character; 
isa  character; 
isa  character; 
isa  character; 
isa  character; 
isa  unit : 

: un i t=un ita ; 
isa  unit; 

:  uni t  =  un  itb ; 


um t c  isa  unit; 
m^'f  ile:unit  =  unitc: 

1 inea  isa  line: 

1 i nea : chars=chara ; 
linea:includes-unit=unitb; 
unita:unit-contents=linea; 
lineb  isa  line; 

1 i neb ; chars  =  charb ; 
unitb:unit-contents=lineb: 
linecd  isa  line; 

1 i need : chars=charc ; 

1 i need : chars=chard ; 
linecd:includes-unit=unita; 
unitc:unit-contents=l inecd ; 
linee  isa  line: 

1 inee:chars=chare; 
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insert  purgel  isa  purge -command; 
insert  purgel :current-unit=unitb; 
insert  updatel  isa  update-command; 
insert  updatel : cur rent- f ile=myf ile ; 
insert  updatel : update -sub-commands=purgel ; 
insert  de1ete2  isa  delete-command; 
insert  delete2 : 1 ine-to-del=linea; 
insert  change2  isa  change-command; 
insert  change2 : change -sub-commands® del ete2 ; 
insert  change2: current-unit=unita; 
insert  update2  isa  update-command; 
insert  update2 ; update -s ub-commands=change2 ; 
insert  update2 : cur  rent- f ile=myfile; 


insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 

■insert 

insert 


1 i ne3  isa  line: 

1  ine3; include s-unit=unitc: 
insert3  isa  insert-command; 
i  nse  rt3 : insert-data®! ine3 ; 
changes  isa  change-command; 
changes : change -sub-commands® i nse  rt3 ; 
changes ; current-unit=unita ; 
updates  isa  update-command; 
updates : update  -  sub-commands  =  change3 ; 
updates : cur  rent- f i le=myf ile: 


insert  modify^  isa  modify-command; 

insert  modify4:line-to-mod=linecd; 

insert  modi fy4 : ol dchar*charc ; 

insert  modify4 : newchar*charz ; 

insert  change4  isa  change-command; 

insert  change4: change -sub-commands=mod if y4 ; 

insert  change4: cur  rent-unit® unite; 

insert  update4  isa  update-command; 

insert  update 4; update-sub-commands=change4 ; 

insert  update4:current-f il e=myf ile; 


insert 

insert 

insert 

insert 

insert 

insert 

insert 

insert 


inserts  isa  insert-command; 
insert5;insert-data=l inee ; 
changes  isa  change-command; 
changes : change -sub-commands® i nse rtS ; 
changes: cur  re nt-unit=unitc; 
updates  isa  update-command; 
updates : update  - sub-commands  =  changeS ; 
updates: cur  re nt-f i le=myf ile; 
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insert  modify6  isa  modify-command; 
insert  inodify6;oldChar=char{l; 
insert  mod i fy6 : newchar*chara; 
insert  cliange6  isa  change-command; 
insert  change6: change-sub-commands=modify6; 
insert  change6: current-unit=onitc ; 
insert  updateE  isa  update-command; 
insert  update6: update -sub-commands® changes ; 
insert  updates : cur  re nt-f ile=myf i 1 e 
end  atomic 
end .  . 

9  0  -  g  i  s  t 


••••  c  I  s  T  •••• 


type  "help"  for  command  list 
( re ) p roces s i ng  declarations 
3->GTRACE(T] 

T 


4- > i n  it 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

i  n  se  rt i ng 

inserting 

inserting 

inserting 

inserting 

inserting 

inserting 

i nse rt  ing 

inserting 

inserting 


myproject  isa  project  in  cx:2 

mylibrary  isa  library  in  cx:2 

myf ile  isa  file  in  cx:2 

myproject  ;  library  «  mylibrary  in  cx:2 

mylibrary  :  file  »  myfile  in  cx:2 

chara  isa  character  in  cx:2 

charb  isa  character  in  cx:2 

chare  isa  character  in  cx:2 

chard  isa  character  in  cx:2 

chare  isa  character  in  cx:2 

charz  isa  character  in  cx:2 

unita  isa  unit  in  cx;2 

myfile  ;  unit  =  unita  in  cx:2 

unitb  isa  unit  in  cx:2 

myfile  :  unit  ®  unitb  in  cx:2 

unite  isa  unit  in  cx:2 

myfile  ;  unit  =  unite  in  cx;2 

1  inea  isa  line  in  cx :2 

linea  :  chars  =  chara  in  cx:2 

linea  :  includes-unit  ®  unitb  in  cx:2 

unita  :  unit-contents  =  linea  in  cx:2 

1 i neb  isa  line  in  cx ; 2 

lineb  ;  chars  =  charb  in  cx;2 

unitb  :  unit-contents  =  lineb  in  cx:2 

1  inecd  isa  line  in  cx :2 

linecd  :  chars  =  chare  in  cx:2 

linecd  :  chars  =  chard  in  cx;2 

linecd  :  includes-unit  *  unita  in  cx;2 

unite  :  unit-contents  *  linecd  in  cx;2 

linee  isa  line  in  cx:2 

linee  :  chars  »  chare  in  cx;? 

purgel  isa  purge-command  in  cx;2 
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inserting  purgel  :  current-unit  *  unitb  in  cx:2 

inserting  updatel  isa  update-command  in  cx:2 

inserting  updatel  :  current-file  =  myfile  in  cx:2 

inserting  updatel  :  update-sub-commands  «  purgel  in  cx:2 

inserting  de1ete2  isa  delete-command  in  cx:2 

inserting  delete2  :  line-to-del  «  linea  in  cx:2 

inserting  change2  isa  change-command  in  cx:2 

inserting  change2  :  change-sub-commands  »  delete2  in  cx:2 

inserting  change2  :  current-unit  ®  unita  in  cx:2 

inserting  update2  isa  update-command  in  cx:2 

inserting  update2  :  update-sub-commands  =  change2  in  cx:2 

inserting  update2  :  current-file  =  myfile  in  cx:2 

inserting  line3  isa  line  in  cx:2 

inserting  line3  :  includes-unit  =  unite  in  cx:2 

inserting  insert3  isa  insert-command  in  cx:2 

inserting  insert3  :  insert-data  =  line3  in  cx:2 

inserting  change3  isa  change-command  in  cx:2 

inserting  change!  :  change-sub-commands  =  insert!  in  cx:2 

inserting  change!  :  current-unit  =  unita  in  cx;2 

inserting  update!  isa  update-command  in  cx:2 

inserting  update!  :  update-sub-commands  =  changes  in  cx:2 

inserting  update!  :  current-file  =  myfile  in  cx:2 

inserting  modifyA  isa  modify-command  in  cx;2 

inserting  modifyA  ;  line-to-mod  =  linecd  in  cx;2 

inserting  modifyA  :  oldchar  =  chare  in  cx:2 

inserting  modifyA  ;  newchar  =  charz  in  cx:2 

inserting  changeA  isa  change-command  in  cx:2 

inserting  changeA  :  change-sub-commands  ®  modifyA  in  cx:2 

inserting  changeA  :  current-unit  *  unite  in  cx:2 

inserting  updateA  isa  update-command  in  cx:2 

inserting  updateA  :  update-sub-commands  =  changeA  in  cx:2 

inserting  updateA  :  current-file  =  myfile  in  cx:2 

inserting  inserts  isa  insert-command  in  cx:2 

inserting  inserts  :  insert-data  *  linee  in  cx:2 

inserting  changes  isa  change-command  in  cx:2 

inserting  changes  :  change-sub-commands  =  inserts  in  cx;2 

inserting  change!  :  current-unit  =  unite  in  cx;2 

inserting  update!  isa  update-command  in  cx;2 

inserting  update!  :  update-sub-commands  =  changes  in  cx:2 

inserting  update!  :  current-file  =  myfile  in  cx:2 

inserting  modifyS  isa  modify-command  in  cx:2 

inserting  modifyS  ;  oldchar  =  chard  in  cx:2 

inserting  modifyS  :  newchar  =  chara  in  cx:2 

inserting  changes  isa  change-command  in  cx:2 

inserting  changes  :  change-sub-commands  =  modifyS  in  cx:2 

inserting  changes  :  current-unit  =  unite  in  cx:2 

inserting  updates  isa  update-command  in  cx:2 

inserting  updates  :  update-sub-conmands  =  changes  in  cx:2 

inserting  updates  :  current-file  =  myfile  in  cx:2 

5- >.  . 

charb : : chars . . 

1  i  neb 

6- >.  . 

1 i neb ; chars . . 
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charb 

7- >.  . 

1inecd:chars. . 
chare 

8- >redo  7 
chard 

9- >redo  7 
chare 

10- >redo  7 
chard 

11- >redo  7 
chare 

12- >redo  7 
chard 

13- >.  . 

exists  file  |  f i 1 e : un i t : uni t-contents  =  Tinea.. 

(TRUE  ((file  .  misfile))) 

14- >.  . 

linee: ;unit-con tents.  . 

Failed... 

15- >  .  . 

UPDATE[updatel] .  . 

UPDATE:  • 

update-command  =  updatel 
PURGE : 

unit  s  unitb 
Failed... 

16- >why 

failing  precondition: 

not  there  exists  i ncl udi ng-uni t :unit , 1 ine  |  i ncl udi ng-un i t : unit-contents= 
line  and  1 ine : includes-unit*unit. . 

Variable  bindings; 

((unit  .  unitb ) ) 

17- >.  . 

PURGE [un ita]  .  . 

PURGE  : 

unit  =  unita 
Failed.  .  . 

18- >why 

failing  precondition: 

not  there  exists  including-unit : unit , 1 ine  |  i ncl uding-un i t : unit-contents® 
line  and  1 i ne : includes-unit  =  unit . . 

Variable  bindings; 

((unit  .  unita)) 


19->.  . 

UP0ATE[update2].  . 
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UPDATE: 

update-command  »  update2 

CHANGE: 
unit  =  unita 
change-command  -  change2 

DELETE: 
unit  =  unita 

delete-command  =  de1ete2 

deleting  unita  :  unit-contents  =  linea  in  cx:7 

DELETE  completed 

CHANGE  completed 

UPDATE  completed 

success 

20->.  . 

unita:unit-contents .  . 

Failed... 

21->.  . 

destroy  myf i 1 e . . 

deleting  myfile  isa  file  in  cx:ll 
deleting  mylibrary  :  file  =  myfile  in  cx:ll 
deleting  myfile  :  unit  =  unite  in  cx:ll 

deleting  myfile  ;  unit  =  unitb  in  cx;ll 

deleting  myfile  :  unit  =  unita  in  cx:ll 

deleting  updates  :  current-file  =  myfile  in  .cx:ll 

deleting  updates  :  current-file  =  myfile  in  cx;ll 

deleting  update4  ;  current-file  =  myfile  in  cx.-ll 

deleting  updates  :  current-file  =  myfile  in  cx.-ll 

deleting  updates  :  current-file  =  myfile  in  cx:ll 

deleting  updatel  ;  current-file  =  myfile  in  cx;ll 

Failed.  .  . 

22- >why 

count  spec  constraint  violation; 

(( cu rrent-f i 1 eof update-command  myfile  updatel) 

(1  .  1) 

:  0) 

23- >??  10  thru  20 


10.  redo  7 

-> . .  1  inecd  :  chars 
chard 

11.  redo  7 

->..  linecd  :  chars 
chare 

12.  redo  7 

->..  linecd  ;  chars 
chard 

13.  ->..  exists  file  1  file  :  unit  :  unit-contents  *  linea 
(TRUE  ((file  .  myfile))) 

14.  ->..  linee  ::  unit-contents 
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Failed. . . 

15.  ->..  UPDATE  %[  updatel  X] 
Failed. . . 

16.  ->why 

17.  PURGE  X[  unite  X] 

Failed. . . 

18.  ->why 

19.  UPDATE  X[  update2  X] 
success 

20.  unita  :  unit-contents 
Failed. . . 


23- >.  . 

UPDATE[updatel].  . 

UPDATE: 

update-command  =  updatel 
PURGE: 

unit  =  unitb 

deleting  unitb  isa  unit  in  cx:14 
deleting  myfile  :  unit  »  unitb  in  cx:14 
deleting  linea  :  includes-unit  «  unitb  in  cx;14 
deleting  unitb  :  unit-contents  *  lineb  in  cx:14 
deleting  purgel  :  current-unit  =  unitb  in  cx:14 
deleting  lineb  isa  line  in  cx:14 
deleting  lineb  :  chars  =  charb  in  cx:14 
deleting  unitb  ;  unit-contents  =  lineb  in  cx:14 
PURGE  completed 
UPDATE  completed 
success 

24- >.  . 

insert  lineg  isa  line., 
inserting  lineg  isa  line  in  cx:17 
success 

25- >.  . 

insert  lineg:chars  =  charb.. 

inserting  lineg  :  chars  =  charb  in  cx:lB 

success 

26- >  .  . 

insert  unitg  isa  unit., 
inserting  unitg  isa  unit  in  cx:19 
Failed. . . 

27->why 

count  spec  constraint  violation: 

((unitoffile  unitg  unitg) 

(1  .  1) 

::  0) 


28->.  . 
atomic 
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insert  unitg  isa  unit; 
insert  unitg: :unit  ■  myfile 
end  atomic. . 

inserting  unitg  isa  unit  in  cx:20 
inserting  myfile  :  unit  >  unitg  in  cx:20 
success 

29- >.  . 

insert  unitg:unit-contents  =  lineg.. 

inserting  unitg  :  unit-contents  =  lineg  in  cx:21 

success 

30- >.  . 

exists  unit  |  UNIT-INCLUDES(unit, unitg). . 

(FALSE) 

31- >.  . 

insert  linea: inciudes-unit  =  unitg.. 

inserting  linea  :  includes-unit  =  unitg  in  cx:22 

success 

32- >.  . 

insert  unita:unit-contents  =  linea.. 

inserting  unita  :  unit-contents  =  linea  in  cx:23 

success 

33- >.  . 

exists  unit  \  UNIT-INCLLJDES( uni t  .unitg) . . 

(TRUE  ((unit  .  unite))) 

34- >redo  33 

(TRUE  ((unit  .  unita))) 

35- >redo  33 

(TRUE  ( (unit  .  unite )) ) 

36- >.  . 
a  unit 

unita 

37- >.  . 

a  unit., 
unitg 

38- >redo  36  thru  37 
unite 

un  i  tc 

39- >redo  38 
un  i  ta 
unitg 

40- >redo  38  thru  39 
unite 

unita 

unite 

unitg 

41- >??  16  thru  20 


16.  ->..  UPDATE  %[  updatel  %] 

Failed. . . 

16.  ->why 


17.  ->..  PURGE  X[  unita  X] 

Failed. . . 
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18.  ->why 

19.  ->..  UPDATE  «[  update2  %] 
success 

20.  ->..  unite  ;  unit-contents 
Failed. . . 
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6.2  IOC  TRACE  -  CAMELOT  EXAMPLE 

Below  is  a  trace  of  a  user  interacting  with  the  IOC  to  explore  behavior  of  the  CAMELOT 
specification.  This  is  a  specification  of  a  process  involving  people  and  familial  relationships.  It  was 
created  for  the  purpose  of  testing  and  demonstrating  iOC  capabilities. 

88<-Read  CAMELOT. GST 

93<-Pretty 

begin 

type  person(any  child:person: ;0  through  2,sex, optional  spouse:person: : 
optional ) 
bound  print 
by= :sex, =; : chi  1 d ; 
type  sex; 

always  prohibited  OEDIPUS«-COMPLEX  there  exists  person  ] 
person : spouse  =  pe  rson :chi Id ; 

always  prohibited  INCEST  there  exists  person, 1 , person . 2  | 

(person. 1: :child  =  person.2; :child)and(person.l: spouse  =  pe  rson . 2) ; 
always  prohibited  SPOLISES<-OF«-SAME*-SEX  there  exists  person. 1, 

person. 2  | 

.(person . 1 ; spouse=person. 2 )and(person. 1 : sex'person . 2: sex ) : 


action 

MARRY[person.l, person. 2] 

definition  atomic  insert  person . 1 :spouse*person . 2 ; 

insert  person . 2 :spouse=person . 1 
end  atomic; 


action 

MAKECHILDfperson] 

precondition  there  exists  person.!  |  person : spouse=person . 1 
let  gender;sex=a  sex 
definition  atomic  create  person. 3; 

insert  person. 3:sex=gender; 
insert  person : chi ld=person . 3 ; 
insert  person: spouse ; child* person. 3; 
case  gender  of 

male=>GISTPR2NT{;"It's  a  boy!"]; 
female=>GISTPRINT[”It's  a  girl!"]; 
end  case 
end  atomic; 


action 

DIVORCE [per son .1, person. 2] 

precondition  person.!: spouse* person. 2 
definition  atomic  delete  person.  1  :spouse*person. 2; 

delete  person. 2 :spouse*person. 1 
end  atomic; 


IOC  TRACE  ••  CAMELOT  EXAMPLE 


atomic  insert  male  isa  sex; 

insert  female  isa  Sex; 
insert  arthur  isa  person; 
insert  arthur; sex=male ; 
insert  guenevere  isa  person; 
insert  guenevere:sex=female; 
insert  lancelot  isa  person; 
insert  larcelot : sex=male 
end  atomic 
end.  . 

94«-gist 


••••  GIST  •••* 

type  "help"  for  command  list 
( re)processin9  declarations 

2- >GlSTPRINTDF.PTH[l] 

1 

3- >GTRTACE[T] 

=GTRACE 

T 

4- >init 

inserting  male  isa  sex  in  cx;2 
inserting  female  isa  sex  in  cx:2 
inserting  arthur  isa  person  in  cx:2 
inserting  arthur  ;  sex  «  male  in  cx:2 
inserting  guenevere  isa  person  in  cx:2 
inserting  guenevere  :  sex  =  female  in  cx;2 
inserting  lancelot  isa  person  in  cx:2 
inserting  lancelot  :  sex  =  male  in  cx:2 

5- >.  . 

MARRY[arthur, guenevere] . . 

MARRY: 

person. 1  =  arthur  :sex  =  male 

person. 2  =  guenevere  ;sex  =  female 

inserting  arthur  :  spouse  =  guenevere  in  cx;4 
inserting  guenevere  :  spouse  =  arthur  in  cx:4 
MARRY  completed 
success 

6- >.  . 

MAKECHILD[arthur] .  . 

MAKECHILD; 

person  «  arthur  :sex  *  male 

inserting  per0029  isa  person  in  cx:7 
inserting  per0029  :  sex  *  male  in  cx;7 
inserting  arthur  :  child  »  per0029  in  cx;7 
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inserting  guenevere  ;  child  »  per0029  in  cx:7 
It's  a  boyi 
MAKECHILO  completed 
success 

7- >. . 

arthur:chi1d:sex  .. 
male 

8-  >.  . 

gueneve re : chi  1 d; sex  .. 
male 

9- >. . 

male ; : sex .  . 
per0029 

10- >redo 
lancelot 

11- >.  . 

per0029 : : sex  . . 

Failed... 

12- >.  . 

per0029 : ; chil d  .  . 
guenevere 

13- >redo 
arthur 

14- >redo  12  thru  13 
guenevere 

arthur 

15- >.  . 

male : ; sex : : chil d  .  . 
gueneve  re 

16- >  redo 
gueneve  re 

17- >0K 
T 

QS^-In 


96^Next  -1 


97*'Pretty 

atomic  insert  male  isa  sex; 

insert  female  isa  sex; 
insert  arthur  isa  person; 
insert  arthu r : sex=mal e ; 
insert  guenevere  isa  person; 
insert  gueneve re : sex=f emal e ; 
insert  lancelot  isa  person; 
insert  lancelot;sex=male 

end  atomic. . 

98*-Before 

relation  PARENT«-IN<-LAW(z;person,y:person)  definition  z:spouse;  :child=y 


99*-T  op 
2*-gist 


lOCTRACE  CAMEtOT  EXAMPLE 
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••••  GIST  •••• 

type  "help"  for  command  list 
( re)process ing  declarations 

18- >GUNTRACE[T] 

NIL 

19- >arthur : spouse 
u.b.a. 

arthur : spouse 

20- >.  . 

arthur; spouse  . . 

Failed. . . 

21- >UND0  16 
redo  undone. 

22- >.  . 

arthur ; spouse  . . 
gueneve  re 

23- >. . 

exists  pl;person,p2:personl  PARENT»-IN<-LAW(pl ,  p2 ) .  . 

(FALSE) 

24- >. . 

MARRY[lancelot.arthur;child].. 

MARRY: 

person. 1  =  lancelot  :sex  =  male 

person. 2  =  per0029  :sex  =  male 

: : ch i 1 d  =  arthur 

gueneve  re 

inserting  lancelot  :  spouse  =  per0029  in  cx:10 
inserting  perC029  :  spouse  =  lancelot  in  cx:10 
Failed. . . 

26->why 

Constraint  Violation: 

always  prohibited  SPOLISES<-OF«-SAME<-SEX  there  exists  person. 1, 

person. 2  | 

(person. l:spouse= person. 2) an d(person.l;sex=person.2:sex).. 
Variable  bindings: 

((person. 1  .  lancelot)  (person. 2  .  per0029)) 

NIL 

26->.  . 

KAKECHILD [arthur].. 

MAKECHILD: 

person  *  arthur  :sex  =  male 

inserting  perC031  isa  person  in  cx:12 
inserting  per0031  :  sex  *  male  in  cx;12 
inserting  arthur  :  child  *  per0031  in  cx:12 
inserting  guenevere  :  child  >  perOOSl  in  cx:12 
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It's  8  boy! 

MAKECHILD  Completed 
success 

27- >redo 

MAKECHILD; 

person  =  arthur  :sex  =  male 

inserting  per0032  is£  person  in  cx;15 
inserting  per0032  :  sex  =  female  in  cx;15 
inserting  arthur  :  child  =  per0032  in  cx:l5 
inserting  guenevere  :  child  =  per0032  in  cx:15 
It's  a  girl! 

MAKECHILD  completed 
success 

28- >.  . 

exists  pi :  person ,  p2 ;  pe rson  I  PARENT*-IN<-LAW(pl .  p2 ) .  . 

(FALSE) 

29- >.  . 

MARRY [1 ancelot.arthur:child].  , 

MARRY; 

person. 1  *  lancelot  :sex  =  male 

person. 2  =  per0032  ;sex  =  female 

;; child  *  arthur 

guenevere 

inserting  lancelot  :  spouse  =  per0032  in  cx;18 
inserting  per0032  :  spouse  =  lancelot  in  cx:18 
MARRY  completed 
success 

30- >  .  . 

exists  pi : person , p2  :  person  (  PAR£NT‘-IN«-LAW(pl ,  p2 ) .  . 

(TRUE  ((pi  .  lancelot)  (p2  .  guenevere))) 

31 - >  redo 

(TRUE  ((pi  .  lancelot)  (p2  .  guenevere)).) 

32- >  .  . 

loop  (a  person)  PARENT*'IN<-LAW(  lancelot, person) )  do  GISTPR1NT[  pe  rson]  . . 
guenevere  :sex  =  female 

arthur  ;sex  =  male 

success 
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7.  DESIGN  FOR  A  GIST  SPECIFICATION 
VALIDATION  FACILITY 

7.1  OBJECTIVE 

The  objective  of  a  Gist  Specification  Validation  Facility  will  be  to  determine  the  feasibility  of 
validating  a  functional  specification,  treated  as  an  oporational  system  prototype,  through  observation 
of  its  behavior  on  both  concrete  and  symbolic  data.  Existing  technology  will  be  extended  to  develop 
and  demonstrate  a  prototype  tool  which  aids  a  system  design  specialist  in  generating,  documenting, 
and  validating  operational  (executable)  software  requirements  specifications. 

7.2  BACKGROUND 

Formal  specifications  act  as  a  contract  between  clients  and  implementors.  Since  the 
implementation  costs  are  so  high  and  the  implementation  delays  so  long,  it  is  crucial  that  the  formal 
specification  accurately  portray  the  client’s  needs.  Much  time,  money,  and  effort  has  been  wasted 
because  of  mismatches  between  specifications  and  client  needs. 

This  effort  attempts  to  mitigate  this  problem  by  developing  a  methodology  for  using  formal 
specifications  as  system  prototypes  and  validating  them  through  observation  of  their  behavior 
produced  by  symbolic  evaluation. 

There  are  two  key  technical  aspects  to  this  approach.  First,  the  creation  of  a  high-level  formal 
operational  specification  language  and  an  interpreter  of  tnat  language.  This  enables  the  formal 
specifications  to  be  used  as  a  prototype.  Second,  a  symbolic  evaluator  of  this  formal  specification 
language  which  enables  entire  classes  of  test  cases  to  be  explored  simultaneously.  Such  collapsing 
of  the  space  of  test  cases  for  the  prototype,  enables  it  to  be  "exhaustively"  tested  to  ascertain 
v;hether  it  meets  client  needs. 

Both  of  these  capabilities  exist  in  rudimentary  form  in  the  SAFE  project  at  ISI,  and  their  extraction 
from  SAFE  and  extension  are  the  foundation  of  this  effort.  Under  this  contract  we  have  provided  the 
first  of  these  tv./o  required  capabilities:  the  creation  of  a  formal  operational  specification  language  and 
an  interpreter  of  that  language  (see  Chapters  2  and  5).  An  initial  operating  capability  (IOC)  exists  (see 
Chapter  5)  which  allows  a  user/analyst  to  enter  input  data  required  by  a  formal  specification 
(prototype)  and  "run"  the  prototype,  monitoring  selected  events  or  breaking  upon  specified 
situations,  as  with  normal  DDT-like  debuggers,  except  that  all  interactions  are  at  the  conceptual 
specification  level,  rather  than  the  low  level  representation-dependent  implementation  level. 
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Since  symbolic  evaluation  is  so  central  to  this  effort,  we  will  explain  it  in  more  detail  here  before 
describing  our  approach.  The  purpose  of  symbolic  execution  is  to  expose  the  behavior  of  a 
specification  on  a  class  of  inputs  rather  than  just  on  a  single  test  case  as  would  occur  with  a  normal 
(nonsymbolic)  evaluator.  This  capability  arises  from  the  ability  to  recognize  assumptions  implicit  in 
the  specification  and  to  incorporate  them  as  fuller  descriptions  of  the  incomplete  (symbolic)  inputs, 
and  from  the  ability  to  explore  all  conditional  paths  in  the  specification  and  to  annotate  the  behavior 
of  such  paths  with  their  conditionality. 

The  size  of  the  class  of  test  cases  being  explored  by  a  symbolic  execution  depends  upon  the 
degree  of  "symbolicness"  of  the  input  and  initial  data  base  description,  and  upon  the  amount  of 
refinement  provided  by  the  user/analyst  during  the  symbolic  execution.  "Symbolic"  and  "Concrete" 
should  be  recognized  as  the  endpoints  of  a  spectrum  of  degrees  of  completeness  of  description.  At 
the  concrete  endpoint,  the  description  of  the  input  (and  initial  data  base)  is  complete  so  that  all 
information  required  during  evaluation  is  already  present.  Therefore  evaluation  can  proceed  in  a 
normal  (nonsymbolic)  manner,  with  data  accessed  as  needed  and  conditional  branching  determined 
by  the  available  concrete  data.  A  single  test  case  execution  results. 

As  the  description  of  the  input  (and  initial  data  base)  becomes  more  symbolic  (incomplete),  some  of 
the  information  needed  during  evaluation  is  not  available.  One  of  two  options  must  be  selected 
before  evaluation  can  proceed; 

1 .  The  needed  information  is  provided  (dynamically)  by  the  user/analyst. 

2.  The  needed  information  is  treated  "symbolically"  so  that  its  presence  and  value  are 
unknown  and  the  full  conditionality  of  the  specification  (with  respect  to  this  needed 
information)  is  explored. 

With  the  first  option,  the  symbolic  evaluation  is  being  used  to  incrementally  define  a  test  case,  or 
class  of  test  cases,  of  interest.  The  symbolic  evaluation,  rather  than  the  user/analyst,  determines 
what  information  is  relevant  for  the  definition  of  different  test  cases. 

With  the  second  option,  a  class  of  test  cases  being  simultaneously  explored  is  formed.  The  more 
this  option  is  employed,  the  larger  the  class  of  test  cases  becomes.  However,  the  complexity  of  the 
behavior  of  the  specification  on  that  class  of  test  cases  also  rises  proportionately  so  that 
understanding  that  behavior  becomes  correspondingly  more  difficult. 

Thus  a  balance  must  be  struck  between  reducing  the  number  of  classes  of  test  cases  to  explore 
and  increasing  the  complexity  of  behavior  of  the  specification  on  those  classes.  For  this  reason,  the 
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symbolic  evaluator  will  be  interactive  so  that  the  user /analyst  can  control  the  definition  of  test  cases 
class  size  and  their  corresponding  complexity. 

A  short  example  may  help  clarify  these  issues.  The  example  is  taken  from  the  Program  Support 
Library,  that  we  have  formally  specified  under  this  contract  (see  Chapter  3).  Let’s  assume  that  we 
want  to  test  the  specification’s  behavior  on  insertion  of  lines  into  an  existing  unit.  We  therefore  create 
a  symbolic  command  leaving  unspecified:  the  sequence  of  lines  to  insert,  the  unit  into  which  the 
insertion  is  to  be  made,  and  the  specification  of  the  location  at  which  the  insertion  is  to  occur. 
However,  since  we  are  only  interested  in  the  insertion  behavior,  we  concretely  specify  the  command 
type  as  an  insertion  command.  With  this  set  of  choices  the  initial  data  base  is  merely  the  symbolic 
command  that  we’ve  created  and  it  is  passed  as  the  input  to  the  specification. 

We  now  start  the  symbolic  execution.  The  specification  first  determines  what  type  of  command  is 
being  processed  Since  this  is  concretely  specified  as  an  insertion  command,  execution  proceeds 
normally.  Next,  the  specification  attempts  to  access  the  unit  specified  in  the  command.  Since  this 
was  unspecified,  the  symbolic  evaluator  asks  the  user/analyst  whether  he  wants  to  make  a  concrete 
choice  or  not.  If  the  user/analyst  chooses  to  supply  a  concrete  unit,  then  he  either  specifies  an 
existing  one  (we  have  assumed  that  none  were  predefined  in  the  initial  data  base)  or  creates  a  new 
one  specifying  whatever  attributes  he  desires.  Such  dynamic  specification  of  concrete  data  is  simply 
a  need  driven  incremental  definition  of  the  initial  data  base.  On  the  other  hand,  if  he  doesn’t  want  to 
supply  a  concrete  unit,  the  system  will  create  a  new  symbolic  unit  and  proceed. 

After  several  more  information  gathering  steps  similar  to  the  one  above,  the  symbolic  evaluator 
reaches  the  crucial  step  for  this  class  of  test  cases  -whether  the  insertion  point  exists  within  the 
sequence  of  lines  which  constitute  the  contents  of  the  unit.  If  both  the  sequence  and  the  insertion 
point  are  concrete,  then  the  insertion  point  either  is  in  the  sequence  or  not,  and  this  can  be 
determined  by  normal  evaluation.  On  the  other  hand,  if  either  or  both  values  are  symbolic,  there  is  no 
v.'ay  to  make  this  determination.  In  such  situations,  the  user/analyst  is  asked  which  of  three  options 
should  be  explored. 

1.  Pursue  the  TRUE  branch  of  the  predicate  by  constraining  the  symbolic  value(s)  so  that 
the  predicate  would  be  TRUE. 

2.  Pursue  the  FALSE  branch  of  the  predicate  by  constraining  the  symbolic  value(s)  so  that 
the  predicate  would  be  FALSE. 

3.  Pursue  both  branches  by  leaving  the  decision  symbolic.  This  enlarges  the  class  of  test 
cases  being  explored. 
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Let's  assume  that  the  third  option  is  selected  by  the  user/analyst.  The  symbolic  evaluator  would 
then  pursue  branches  separately  by  suitably  constraining  the  symbolic  value(s)  in  each  branch.  The 
activity  of  each  branch  would  be  marked  by  the  conditionality  of  the  predicate  so  that  after  the 
branches  joined,  the  system  could  determine  the  conditionality  of  the  respective  behaviors  and  thus 
their  interaction  with  later  activity. 

In  this  specific  case,  this  dual  exploration  is  pa>ticularly  simple  since  one  branch  terminates  in  an 
error  (the  insertion  point  is  not  within  the  contents  of  the  unit)  and  thus  the  branches  do  not  rejoin. 
It’s  quite  evident  that  as  the  size  of  the  class  of  test  cases  being  explored  grows,  the  difficulty  of 
clearly  explaining  this  behavior  in  terms  of  the  internal  branch  points  increases.  We  expect  such 
explanation  capabilities  to  be  the  major  portion  of  this  effort. 

7.3  APPROACH 

This  two-year  effort  will  build  upon  the  foundation  established  by  the  existing  contract  via  a 
continued  phased  introduction  of  capabilities  from  the  SAFE  project  to  extend  the  ICXii  into  the 
symbolic  evaluation-based  specification  validation  facility  required. 

First,  SAFE  capabilities  to  record  and  interrogate  execution  behavior  will  be  integrated  into  the  IOC. 
This  is  necessary  because  the  existing  IOC  only  maintains  a  dynamically  changing  "current  state"  of 
the  world  being  modeled  in  the  relational  data  base.  Since  we  are  interested  in  explaining  the 
behavior  of  the  system  (i.e.,  its  sequence  of  actions)  which  produced  some  final  state,  rather  than 
merely  describing  the  final  state,  recording  and  saving  the  intermediate  activity  is  crucial.  Such 
recording  produces  a  data  base  of  behavior  which  can  be  accessed  to  provide  summarized 
descriptions  of  activity  used  to  validate  the  specification.  To  obtain  such  summarized  descriptions,  a 
tool  which  interrogates  this  data  base  and  organizes  the  information  it  contains  into  activity 
surrimaries  (explanations  of  behavior)  must  be  built.  This  is  the  major  new  research  proposed  under 
this  contract.  To  gain  experience  with  creating  such  summaries  and  to  provide  a  fallback  position  in 
case  such  automatic  activity  summarization  proves  infeasible,  a  set  of  interactive  user/analyst 
commands  for  examining  the  recorded  behavior  will  first  be  provided. 


L  _  _ 


At  this  point,  a  capability  would  exist  for  validating  formal  operational  specifications  by  analyzing 
their  behavior  on  concrete  test  cases.  But  even  at  the  specification  level,  the  number  of  concrete  test 
cases  that  would  have  to  be  explored  to  adequately  validate  the  specification  is  overwhelming.  This 
difficulty  can  be  overcome  by  integrating  the  symbolic  execution  capability  from  the  SAFE  project  into 
this  validation  facility  (as  an  extension  to  the  language  interpreter)  and  extending  the  summarization 
capability  to  include  the  symbolic  data  in  the  recorded  behavior. 
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7.4  PLAN 

The  history  recording  and  interrogation  facility  from  the  SAFE  system  will  be  extracted  and 
integrated  into  the  IOC.  This  facility  records  execution  behavior  and  provides  low-level  operations 
for  examining  this  behavior.  Then,  a  set  of  high-level  user  (analyst)  commands  for  examining  the 
recorded  behavior  will  be  provided.  These  commands  should  provide  the  ability  for  the  user  to  move 
back  and  forth  in  the  history  by  describing  desired  states  (via  GIST  specification  language 
predicates).  These  commands  should  also  provide  the  analyst  with  the  ability  to  determine  which 
portions  of  the  specification  are  responsible  for  each  piece  of  behavior. 

Next  a  tool  which  analyzes  a  recorded  history  and  provides  a  summary  description  will  be  built. 
This  tool  will  use  the  structure  of  the  specification  and  rules  of  program  description  to  summarize  the 
recorded  behavior. 

Then,  the  symbolic  execution  package  from  SAFE  will  be  extracted  and  modified  so  that  it 
interactively  receives  guidance  from  the  user/analyst  as  to  which  execution  paths  to  explore.  A 
bookkeeping  facility  to  keep  the  user/analyst  informed  as  to  which  paths  have  been  explored  and 
which  have  not  yet  been  explored  will  also  be  provided. 

Finally,  the  automatic  summarization  fool  will  be  extended  to  include  descriptions  of  symbolic 
behavior. 
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Below  is  the  grammar  of  Gist  used  in  generating  the  ICX).  The  form  of  the  grammar  is  that  accepted 
by  the  POPART  system.  The  grammar  is  context  free,  represented  as  a  series  of  productions  of  the 
form 

nonterminal ;  =  rewrite 

with  the  following  conventions; 

•  The  rewrite  for  a  nonterminal  symbol  is  a  sequence  of  nonterminal  symbols  and  terminal 
symbols. 

•  Terminal  symbols  are  preceded  by  a  quote  mark  (’). 

•  Alternative  rev^ritings  of  a  nonterminal  are  separated  by  bars  (1). 

•  Lines  of  the  form 


NOTE  ... : 

are  comments  about  the  grammar,  not  productions  of  the  grammar. 

•  Optional  constituents  are  enclosed  in  braces  {). 

•  The  nonterminal  LEXEME  is  predefined  to  allow  any  sequence  of  letters  and  digits  as  its 
rewrite. 

•  A  rev/rite  of  the  form 


nonterminal  1>  predicate 

indicates  that  subset  of  rewrites  of  the  nonterminal  which  satisfy  the  named  unary 
predicate.  The  predicates  are  not  documented  here. 

NOTE  1  Declaration  section; 

DeclarationStatement  ;=  Indi vidualDeclaration 

{  LocalDef initions  ) 

{  IndividualDef inition  } 

{  ConstrainingDeclarations  }; 

Indi vidualDeclaration  :=  TypeDecl aration  ) 

BoundaryDedaration  | 

RelationDeclaration  | 

ProhibitDeclaration  j 
RequireDeclaration  | 

DertvationDeclaration  | 

ActlonOecI aration  | 

DemonOeclaration  ; 


I 


LocalDef initions  :»  'let  LocalDef inition  t  ; 
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LocalDef inition  ;=  Role  ’=  ObjectExpression ; 

Indi vidoalDef inition  ;=  'definition  (Statement  |  Predicate  (  TypeExpression  | 

ObjectExpression  ); 

ConstrainingDecI arat ions  :«  'where  OeclarationOrComment  t  ' ;  {  ’ ;  )  'end; 

Deci arationOrComment  OeclarationStatement  |  ComnentStatement  ; 


BoundaryDeclaration  :=  "boundary  {  Wame  )  BoundarySpecif ication ; 
BoundarySpecif ication  :=  Linkage  f  ',  ; 

Linkage  ;=  LinkClass  Link; 

LinkClass  :=  EquivalenceName  |  Predicate  : 

Equi valenceName  :=  '=  |  'equiv  |  'identical  : 

Link  :=  AttributeRelationship  AttributeName ; 
AttributeRelationship  :=  ':  |  ; 

TypeDeclaration  ;=  'type  {  Name  }  {  '(  AttributeSpec  t  ')  } 

{  TypeRelationQual  if ier  }; 

AttributeSpec  ;=  {  CountSpec  }  AttributeName 

{  TypeExpression  }  {  CountSpec#  }; 
AttributeName  ;=  RoleName  ; 

CountSpec  :=  CountSpecConstant  |  IntegerRange  |  Integer  | 
NestedCountSpec  ; 

IntegerRange  : =  Integer  'through  Integer#; 

NestedCountSpec  '(  CountSpec  t  ')  ; 

CountSpecConstant  :=  'unique  |  'optional  )  'multiple  |  'any; 
TypeRelationQual if ier  :=  TypeQual if ier  |  RelationQual if ier  ; 

Name  :=  LEXEME  1>  Identif ierFilter  ; 

Identifier  :=  LEXEME  |>  Identif ierFil ter  ; 

TypeExpression  :=  TypePrimitive  ; 

TypePrimitive  :=  StructureSpecif ication  | 

SetTerm  | 

OeclarationStatement  ; 

StructureSpec if ication  :=  StructureType  'of  TypeExpression; 
StructureType  :=  Predef inedStructure  |  Identifier  ; 

Predef i nedStructure  :=  'set  1  'sequence  ; 

Rel ationDeclaration  ;=  'relation  {  Name  )  '(  Role  t  ') 

{  Rel ationQual if ier  +  }  ; 

Role  :=  RoleName  {  ':  TypeExpression  )  ; 

RoleName  :=  Identifier  {  '.  Distinguisher  }  ; 

Distinguisher  ;=  IntegerConstant  |  Identifier 
IntegerConstant  :*  LEXEME  ]>  Integer?  ; 

Integer  :=  LEXEME  1>  Integer?  ; 


ProhibitDeclaration  :=  'always  'prohibited  {  Name  )  Predicate; 

Requ i reOecl arat i on  :*  'always  'required  {  Name  }  Predicate; 

OerivationDeclaration  :»  'derivation  {  Name  }  '(  Role  f  ',  ’) 
'whenever  Predicate  'conclude  Pattern  t  ',  ; 

ActionDeclaration  :=  'action  {  Name  }  {  '[  {  Role  t  ',  }  ']  ) 

{  ActionQual if ier  +  }  ; 
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ActionQual if ier  ;=  ActionPrecondition  | 

ActlonPostcondition  ; 

ActionPrecondition  ;=  'precondition  Predicate; 
ActionPostcondition  :»  'postcondition  Predicate; 

DemonDeclaration  ;=  'demon  {  Name  }  '(  Role  t  ',  ') 

'trigger  Predicate 
'response  Statement  ; 


NOTE  2  Statement  definitions; 

Statement  ;=  Decl arationStatement  1 
Requi restatement  | 

ProhibitStatement  ] 

DataPrimiti veStatement  | 

AtomicStatement  | 

BlockStatement  | 

ConditionalStatement  | 

CaseStatement  | 

Actioninvocation  | 

LoopingStatement  j 
CommentStatement  | 

ContinuationStatement  | 

AttemptStatement  1 
ChooseStatement  ( 

TogetherStatement  ; 

Requ i restatement  :=  'require  Predicate; 

Prob i b i tStatemen t  :=  'prohibit  Predicate; 

DataPrimiti veStatement  :*  Datalnsertion  \  DataDeTetion  )  DataUpdete  1 

ObjectCreation  |  ObjectDestruction  |  ObjectCopy  ; 

Datalnsertion  ; *  'insert  {  All  )  Pattern; 

DataDeletion  :=  'delete  {  All  )  Pattern; 

DataUpdate  : =  'update  {  All  }  {  AttributeRelationship  } 

RoleName  OfExpressionOrRelation  'to  Expression; 

OfExpressionOrRelation  :*  'in  Relationship  |  'of  ObjectExpress ion  ; 

ObjectCreation  :=  'create  CreationSpecif ication  t 

{  'with  Pattern  }  ; 

C reat ionSpec i f ication  :=  RoleName  {  ':  NameOrPatte rn  }  {  'wrt  Boundary); 

NameOrPattern  ;=  Pattern  |  RoleName  ; 

Pattern  ;=  Identity  j  Containment  |  Relationship  ; 

ObjectDestruction  :=  'destroy  {  All  )  ObjectExpress ion  {  'wrt  Boundary  ): 

ObjectCopy  :=  'copy  CreationSpecif  ication  •r  ' ,  ; 

All  ;=  'all  : 

AtomicStatement  :*  'atomic  Statement  t  ';  'end  'atomic; 

B1 ockStatement  ;=  'begin  Statement  t  ';  'end; 

ConditionalStatement  :*  'if  Predicate  'then  Statement 

{  ElselfClause  '*’  }  {  'else  Statement# 

CaseStatement  :*  'case  Ob jectExpression  'of  CaseCase  ^  } 

'end  'case  ;  I  • 

CaseCase  :*  ObjectExpression  '«>  Statement;  j 

t 

1. 
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ElselfClause  ;=  'elseif  Predicate  'then  Statement; 
LoopingStatement  ;=  'loop  SetOrSequenceExpress ion  'do  Statement; 
CommentStatement  ;*  'comment  Anyth ingButEnd  +  'end  'comment  ; 

AnythingButEnd  :=  LEXEME  1>  AllButEnd; 

ContinuationStatement  :«  'continuations  'of  Statement 

'from  'which  Expression 
'satisfies  Predicate; 

AttemptStatement  :=  'attempt  Statement  t  ' ;  ; 

Actioninvocation  ;=  Name  '[  {  Expression  ■»  '  ,  }  ']: 

ChooseStatement  :=  'cl  cose  Statement  t  •;  'end  'choose; 
TogetherStatement  :=  'together  Statement  t  ’end  'together; 

NOTE  3  The  extensions  section; 

TypeQual  if ier  :=  BoundaryDef aul t  |  TypeEmbedding  | 

Equi valentForm 

BoundaryDef aul t  :=  'bound  BoundaryOp  t  ',  'by  Boundary; 

BoundaryOp  :=  'copy  |  'destroy  |  'restore  |  'contains  |  'equiv  | 
'mod i fy  |  'all; 

Boundary  :=  BoundarySpecif ication  |  Name  ; 

TypeEmbedding  :=  TypeConnector  'of  '<  TypeDecl arationBody  t  '>  ; 
TypeConnector  :=  {  CountSpec  }  Supertype  |  Subtype; 

Subtype  :=  'subtype; 

Supertype  ;=  'supertype; 

Equi val entForm  :=  LinkClass; 

RelationQual if ier  :=  KeySpecif ication  |  CoversSpecif ication  | 

Re  1  at ionMapp i ngProperty  ; 

KeySpecif ication  :=  'key  KeyRoles; 

KeyRoles  :=  Role  |  '(  ObjectExpression  t  ')  ; 

CoversSpecif ication  :=  'covers  Roles: 

Roles  :=  Role  |  '(  Role  t  ; 

TypeDecl arationBody  :=  Name  {  '(  AttributeSpec  t  • ,  ')  } 

{  TypeRelationQual if ier  +  ) 

{  LocalDef initions  } 

{  IndividualDef inition  ) 

{  Cons t rain i n gDec 1 arat ions  }  ; 

Rel ationMappingProperty  ;=  '  onetoone  (  '  onto  |  'reflexive  | 

'transitive  (  'symmetric  (  'antisymmetric  | 
'nonreflexive  ; 

NOTE  4  Expression  language; 

Expression  :=  ObjectExpression  ; 

SetOrSequenceExpress ion  ;=  SetExpress ion  |  SequenceTerm  ; 
ObjectExpression  :=  SelectedExpression  |  SetExpression  | 

SequenceExpression  |  ArithmeticExpression  | 
SharedExpression  ; 


SharedExpression  :*  SharedFactor  ; 

SharedFactor  ;=  SharedSecondary  {  'asof  Duration  } 
SharedSecondary  :=  {  OldConstant  }  SharedPrimary  ; 

OldConstant  :»  'old  ; 

SharedPrimary  :*  SharedPr imi ti ve 

{  Selectors  )  : 


Selectors  :*  Selector  +  ; 

Selector  ;=  AttributeRelationship  AttributeName ; 
SharedPrimiti ve  :=  FunctionCall  |  Special  Symbol  | 

NestedObjectExpression  |  Variable 

FunctionCall  Identifier  '(  {  ObjectExpression  '  .  }  ' )  : 
SpecialSymbol  ValueSelectedSymbol  |  Wi 1 dCardSymbol  |  ; 
ValueSelectedSymbol  : 

WildCardSymbol  :=  ’$  : 

NestedObjectExpression  :=  *(  ObjectExpression  ’)  ; 

Variable  :=  RoleName  ; 


SelectedExpression  :=  SequenceSelection  J  GeneratorSelection  | 

NondeterministicSelection  |  OptimalSelection 
SequenceSelection  ;=  RandomSelection  1  Fi rstEl ement  1  LastElement 
RandomSelection  :=  SequenceTerm  'sub  ArithmeticTerm  ; 
FirstElement  :=  'first  SequenceTerm; 

LastElement  :=  'last  SequenceTerm; 

GeneratorSelection  :=  Gene ratorTerm  LastWord  ObjectExpression; 

LastWord  :*  'afterwards  |  'lasttime  ; 

NondeterministicSelection  :*  Determiner  Role  {  'I  Predicate  }  ; 

Determiner  'a  |  'an  (  'any  |  ’one  |  'the  ; 

OptimalSelection  :=  OptimizingWord  ObjectExpression  'wrt  Order; 
OptimizingWord  :=  'maximal  |  'minimal  ;  . 

NOTE  Set  expression  subgrammar; 

SetExpression  :»  SetTerm  |>  RejectSharedExpression  ; 

SetTerm  :=  SetFactor  {  DifferenceSetTerm  )  ; 

DifferenceSetTerm  ;=  '-  SetTerm  ; 

SetFactor  ;=  SetSecondary  {  UnionSetFactor  ) 

UnionSetFactor  :=  'union  SetFactor  ; 

SetSecondary  :=  SetPrimary  {  IntersectSetSecondary  }  ; 

IntersectSetSecondary  ;=  'intersect  SetSecondary  ; 

SetPrimary  :=  {  Powerset  }  SetPrimitive  ; 

Powerset  :=  'powerset  ; 

SetPrimitive  :=  EnumeratedSet  1  SetRestr iction  ]  GeneratorTerm  ; 
EhumeratedSet  :=  '{  ObjectExpression  r  •,  •)  ; 

SetRestr ict i on  :=  '{  Role  '|  Predicate  '}  ; 

NOTE  Sequence  Expression  subgrammar; 

SequenceExpress ion  :=  SequenceTerm  |>  RejectSharedExpression  ; 
SequenceTerm  :=  SequenceFactor  {  ConcatenateSequenceTerm  )  ; 

ConcatenateSequenceTerm  :=  '  SequenceTerm  ; 

SequenceFactor  :=  SequenceSecondary  {  LimiterSequenceFactor  }  ; 

LimiterSequenceFactor  :=  Limiter  SequenceFactor; 

Limiter  :*  'before  |  'beyond  ; 

SequenceSecondary  :=  EnumeratedSequence  |  String  | 

GeneratorTerm  ; 

EnumeratedSequence  :«  '<  ObjectExpression  t  ’>  ; 

String  :•  LEXEME  |>  Col lectString ; 
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NOTE  Generator  expressions  subgrammar; 

GeneratorExpression  :=  GeneratorTerm  |>  RejectSharedExpression  ; 
GeneratorTerm  :=  GeneratorFactor  {  TogetherGeneratorTerm  } 
TogetherGeneratorTerm  ;=  Together  GeneratorTerm  ; 

Together  :=  'with  1  'cross  ; 

GeneratorFactor  :=  GeneratorSecondary  {  GeneratorSuf f ixes  }  ; 

Gene ratorSuf f  1  xes  :=  GeneratorSuf f ix  -t  ; 

GeneratorSuff ix  :=  PredicatedFilter  |  EncodingFilter  | 

NamingFilter  |  SequenceTerminator  | 

Accumulation  j  Remainder  |  SubsequenceSeTection  ; 
PredicatedFilter  :=  SuchthatOrUnless  Predicate; 

SuchthatOrUnl ess  :=  'suchthat  |  'unless  ; 

EncodingFilter  ;=  'obtain  ObjectExpression  t  ; 

NamingFilter  ;=  'named  Variable  {  CommaVariable  +  'respectively  }  ; 

CommaVar iabl e  :»  ',  Variable  ; 

SequenceTerminator  ;=  Termi natorWord  Predicate; 

TerminatorWord  :=  'while  ]  'until  ; 

Accumulation  : =  {  'initially  ObjectExpression  } 

'accumulate  ObjectExpression/^  ; 

Remainder  :*  'ungenerated  |  'rest  ; 

SubsequenceSel ect ion  :=  DurationWord  Predicate; 

OurationWord  ;=  'before  ]  'through  |  'after  |  'beyond  ; 
GeneratorSecondary  ;«  PrimitiveGenerator  j  PrimitivePatternGenerator  | 

SharedExpression  ; 

PrimitiveGenerator  ;*  'from  ObjectExpression  'by  ObjectExpression#; 
PrimitivePatternGenerator  :=  SequenceTerminator  ; 

NOTE  Arithmetic  expression  subgrammar; 

ArithmeticExpression  :=  ArithmeticTerm  |>  RejectSharedExpression  ; 
ArithmeticTerm  :=  Ar ithmeticFactor  {  PlusArithmeticTerm  }  ; 

PlusArithmeticTerm  :=  PlusOp  ArithmeticTerm; 

PlusOp  :=  '+  1  '-  ; 

ArithmeticFactor  : =  Ar ithmeticSecondary  {  MultiplyArithmeticFactor  }  ; 

Mul t i plyAr ithmet i cF actor  :=  MultOp  ArithmeticFactor  ; 

MultOp  :=  'x  I  '/  I  'div  |  'mod  ; 

ArithmeticSecondary  ;=  {  ArithmeticPref ixes  )  ArithmeticPrimary 
ArithmeticPref ixes  :=  ArithmeticPref ix  +  ; 

ArithmeticPref  ix  :=  I  '*  |  'ceiling  |  'floor  |  'absolute  ; 
ArithmeticPrimary  :=  ArithmeticPrimitive  {  ExponentArithmeticSecondarys  }  ; 

ExponentArithmeticSecondarys  ;=  ExponentAri thmet icSecondary  +  ; 
ExponentArithmeticSecondary  ;=  '••  ArithmeticSecondary  ; 
ArithmeticPrimitive  ;=  Integer  \  SharedExpression  ; 

NOTE  Predicate  expression  subgrammar; 

Predicate  ;=  Quantif iedLogical  |  DurationPredicate  |  Logicalimp  ; 

Quantif iedLogical  ;=  {  Not  }  QuantHead  Predicate; 

QuantHead  :>  ExHead  |  UnivHead  ; 

ExHead  :*  {  'there  }  'exists  Quantif ierRole  t  ',  '|  ; 

UnivHead  ;=  {  'for  }  'all  Quantif ierRole  t  ',  ; 

Quant  if ierRol e  :*  Role  ; 

DurationPredicate  :*  {  Not  }  AlwaysOrNever  Predicate  'throughout  Duration; 


AlwaysOrNever  :*  'always  |  'never  ; 

Logical  Imp  :=  LogicalTerm  {  'implies  Logical  Imp  ) 

LogicalTerm  ;=  Log ical Factor  {  OrLogicalTerm  )  ; 

OrLogicalTerm  :*  Or  LogicalTerm  ; 

LogicalFactor  LogicalSecondary  {  'and  LogicalFactor  )  ; 

Or  :=  'or  |  'xor  ; 

LogicalSecondary  ;=  {  Logical Pref ixes  )  Logi cal  Primary  ; 
LogicalPref ixes  :*  LogicalPref ix  +  ; 

LogicelPref ix  :*  Not  1  OldConstant  ; 

Not  :=  'not  (  ; 

LogicalPrimary  ;*  Proposition  {  'asof  Duration  )  ; 

Proposition  :=  LogicalConstant  |  Inf ixRel at  ion  | 

Relationship  |  NestedPredicate  : 

LogicalConstant  :=  'TRUE  |  'FALSE  |  'true  |  'false  ; 

Inf ixRelation  :=  Ob jectExpress ion  Compart sonSuff ix  ; 

ComparisonSuf f ix  :=  OrderingRelation  |  OptimizationRelat ion  | 

IdentityRelation  j  ContainmentRel ation 
OrderingRelation  :=  {  Immediately  ) 

Order ingRelationConstant  ObjectExpress ion 
{  'wrt  Order  }  ; 

Immediately  :*  'immediately  ; 

OrderingRel ationConstant  ; =  '<  I  '>  I  'tie  ; 

Order  ;=  Identifier  ; 

OptimizationRelation  ;=  Optimizes  ObjectExpression 

{  'wrt  Order  )  ; 

Optimizes  :=  'minimizes  |  'maximizes  ; 

Identity  ;=  ’=  ObjectExpression  ; 

Relationship  :=  functionCall  ; 

Containment  :=  ContainmentName 

(  ObjectExpression  )  TypeExp ress ion  )  ; 

Conta inmentName  ;=  ElementName  j  ProperSubSuperSet  | 
ProperSubSupe rSequence  ; 

ElementName  : =  'contains  |  'in  |  'isa  )  'isan  ; 
ProperSubSuperSet  ;=  {  Proper  }  SubOrSupe rSet  ; 
ProperSubSuperSequence  :=  (  Proper  )  SubOrSuperSequence 
SubOrSuperSet  : =  'subset  1  'superset  ; 

Proper  ;=  'proper  ; 

SubOrSuperSequence  :=  'subsequence  |  ’supersequence  ; 
NestedPredicate  ;=  ’(  Predicate  ’)  ; 


Duration  ;=  GeneratorTerm 
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Within  this  appendix: 

comments  to  explain  language  features  are  surrounded  by  III 
comments  to  explain  modeling  of  the  task  are  surrounded  by  '  *  * 


11.1  SOURCE  DATA  MAINTENANCE  SPECIFICATION 

11.1.1  •  •  •  Type  definitions  for  objects  of  dornain  *  *  • 

type  projectfLiBRARY  :anv  ::uniaue  ,  classification) 
bound  contains  Jjy  :library 
bound  restore  bv  =  :Classification, 

=  ;library  ; 


type  librarvfFiLE  :anv  ..uniQuel 

bound  contains,  restore  by  =  :file  ; 

type  file(UNiT  :anv  ::uniaue  ,  passworp  :oDtionall 
bound  contains  by  :Unit 
bound  restore  by  =  unit, 

=  :password  ; 

type  unit(UNiT-C0NTENTS  |  sequence gf  line  ,  programmer  , 

UNIT-KEY  I  key  :oDtional ,  source-language  1  language  :optional) 
bound  contains  by  .unit-contents 
bound  =■  restore  bv  =  :unit-C0ntents, 

=  :programmer, 

=  :unitkey, 

=  ISOURCE-LANGUAGE  ; 

type  linefCHARS  I  sequence  of  character  ,  line-includes-unit  I  essence  of  unit  :anv) 
bound  restore  by  =  :CHARS, 

=  :line-incluoes  unit  ; 

type  oasswordO:  type  programmerO:  type  languageO: 

type  kevH:  type  classificationO: 
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JI.1 .2  •  •  •  Static  constraints  on  the  world  • 

These  constrain  the  possible  states  of  the  world  (without  reference  to  changes  in 
the  world,  hence  'static'). 


always  required  UNIT-LINE-LENGTH-CONSTRAINT 
All  lines  in  units  are  of  length  Card-Length  •** 

V  l/ne  II  MEMBER($:UNiT-C0NTENTS,$,//ne)  =»  ( lenathf//ne:CHARSl  =  Card-Length  ) ; 


always  prohibited 

*  •  *  A  line  may  not  occur  more  than  once  in  the  unit-contents  sequence  *  *  * 

3  unit ,  integer^  ,  integer. 2  || 

MEMBER(un/f.UNiT-CONTENTS,/nteger.1,*)  =  MEMBER(un/f:UNiT-CONTENTS,/nte9er.2,*)  ; 


always  prohibited 

A  line  may  not  be  shared  between  units  *** 

3  un/f.1 ,  unit. 2  || 

MEMBER(un/t.T :UhliT-COt<iTENTS  ,$,•)  =  MEMBER{u/7/r.2:UNIT-CONTENTS  ,$,*): 


*  *  *  Inclusion  of  units  may  not  be  'circular'  -  define  a  relation  and  derivations  to  model 
inclusion  between  units  * '  * 

relation  UNIT-INCLUDES-UNiT(/nc/udor  |  unit ,  included  |  unit) ; 

derivation  DERIVE-UNIT-INCLUDES-UNtT(un/f-a  j  unit ,  unit-b  1  unit) 

••*  If  a  line  in  unit-a  includes  unit-b,  derive  that  unit  a  UNIT-INCLUDES-UNIT  unit-b  *  *  * 
whenever  3  line  ||  MEMBER(unrt-a:UNiT-CONTENTS,$,//ne)  A  ( //ne:LiNE-iNCLUDES-UNiT  =  unit-b) 
conclude  UNIT-INCLUDES-UNIT(un;7-3,un/f-b) ; 

derivation  DERIVE-TRANS-CLOSURE-UNIT-INCLUDES-UNIT(un/r-a  |  unit  ,  unit-c  \  unit) 
Form  transitive  closure  of  UNIT-INCLUDES-UNIT  •** 
v.'henever  3  unit-b  |  unit  || 

UNIT-INCLUDES-UNIT(un/:-a,unif-b)  A  UNIT-INCLUDES-UNIT(un/f-£),un;f-c) 
conclude  UNIT-INCLUDES-UNITfunit-a.unir-c) ; 


*"  Now  prohibit  any  circular  UNIT-INCLUDES-UNIT  *•* 
always  prohibited  3unii\\  UNIT-INCLUDES-UNIT(un/7,un/7) ; 
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User  commands 


•  •  *  We  have  chosen  to  model  user  commands  as  a  sequence  of  objects  through  which 
the  system  iterates  (an  alternative  would  have  been  to  expect  the  world  to  invoke  the 
appropriate  action  for  each  user  command). 


•  •  *  file  spec  is  introduced  to  connect  a  file  reference  with  a  password  *  *  • 
type  tile-spec(FiLE,  password  :QDtionall ; 


•  *  *  Definitions  are  indented  to  display  the  type  hierarchy  of  the  commands  *  *  • 
type  commando  supertvoe  of 

<  update-command  ;  copy-file-command  ;  backup-command  ;  restore-command  > ; 


type  update-command(cuRRENT  FILE  SPEC  I  file-spec  , 

UPDATE-SUB  COMMANDS  I  seouence  of  UDdate-sub-command) ; 

type  update-sub-command(cURRENT-uNiT  I  essence  of  unit,  unit- key  |  key  :oDtional)  i 
<  add-command  ;  purge-command  ;  replace-command  ; 
copy-unit-command  ;  change-command  >; 


type  add-command(DATA  |  sequence  of  line,  source-language  |  language  roptional) ; 
type  purge-commandQ; 

type  replace-commandfPATA  I  sequence  of  line) : 

type  copy -unit- command(FROM UNIT  I  essence  of  unit.  from  file-SPEC  I  file-spec  loptional) ; 

type  change-command(CHANGE  SUB  COMMANDS  I  sequence  of  change-sub-command)  ; 

type  temporary-change-command  subt\-De  of  <  change-command  >  ; 

type  chanoe-sub-commandO  supertype  of 

<  insert-command  .  delete-command  ;  shift-command  : 
modify-command  ,  copy-lines-command  ;  replace-line-command  >  , 


i 
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type  insert-command(DATA  I  sequence  of  line,  sequence-location  lOPtionaH  ; 

type  delete-command(LiNES  I  essence  of  seouence  of  llne^ ; 

type  shift-command<LiNES  I  essence  of  seouence  of  line,  columns  |  integer) ; 

type  modify-command (LINES  1  essence  fif  seouencn  Qf  line, 

NEW-STRiNG  |  sequence  Qf  character, 

STARTING-COLUMN  j  integer  loptional. 

OLD-STRING  |  Sequence  of  character  :oDtional^ ; 

type  copy*lines>command(FROMUNiT  I  essence  of  unit. 

LINES  I  essence  Qf  sequence  fif  line, 

SEQUENCE-LOCATION,  FROM-FILE-SPEC  1  file-spec  :oDtionall ; 
type  replace-line-command(OLDLiNE  I  essence  pf  line,  newline  1  line) ; 


type  copy-file-command(TO-FiLE-SPEC  |  file-spec,  from-filE-SPEC  |  file-spec) ; 


type  backup-command(OBjECT  I  essence  of  project  U  library  U  file) ; 

type  restore-command(BACKUP-STATE  j  slate  , 

OBJECT  I  essence  o(  project  U  library  U  file  U  unit) ; 

**•  Note  that  some  of  the  names  of  the  aboye  commands,  and  the  actions  that  are  to 
perform  them,  do  not  correspond  to  the  user  command  names  giyen  in  the  English 
specification.  These  changes  are  intended  to  clarify  the  action  of  the  named  commands. 
COPY  has  become  COPY-LINES 
MOVE  has  become  COPY-UNIT 
MERGE  has  become  COPY-FILE 

Whereas  preyiously  proyiding  sequenced  numbered  data  lines  in  a  CHANGE  command 
implicitly  caused  insertion  or  replacement  of  lines,  now  these  changes  are  achieyed  by 
giying  explicit  commands  INSERT  and  REPLACE-LINE. 


‘I 
•  J 
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always  prohibited  INCLUDED-UNIT-DELETION 
•  •  *  A  unit  may  not  be  deleted  if  it  is  included  anywhere  •  *  * 

3  dead-unit  \  essence  ol  unit  || 
destroyed  csad-unit  A  UNIT-INCLUDES-UNIT($, dead-un/f) ; 


always  required  UNIT-KEY-CHECKING 
*  *  *  May  not  make  changes  to  a  keyed  unit  without  haying  provided  the  correct 
key  in  the  current  command,  except  when  performing  RESTORE  or 
RESTORE-UNITS-TEMPORARILY-CHANGED-SINCE.  •** 

(  3  chanaed-unil  I  essence  of  unit  II 

Idestrovedfun/ft  V  modifiedfi/ri/tl )  A  fil^  {  3  key  =  un/YiuNiT-KEV  )  )  A 
~  (  RESTORE[S]  V  RESTORE-UNITS-TEMPORARILY-CHANGED-SINCE[$] ) 

3  command,  event  || 

active  event  A  (  oarameterofteyenfl  =  command )  A  command:unn-Kty  =  key; 


always  required  PASSWORD-CHECKING 
•*  *  May  not  access  any  part  of  a  passv/ord- protected  file  without  having  provided 
the  correct  password  in  the  file-spec,  except  when  performing  RESTORE  or 
RESTORE-UNITS-TEMPORARILY-CHANGED-SINCE.  *•* 

(  3  file  II  access(file)  A  3  password  ||  password  *  ///e:PASSWORD  )  A 
-  (  RESTORE(S]  V  RESTORE-UNITS-TEMPORARILY-CHANGED-SINCE[$] )  =#• 

3  command,  event,  file-spec  || 

active  event  A  (  narameteroffeven/l  =  command )  A  command  contains  file-spec  A 
(  We-spec  :file  =  ills  )  A  ( f//e-spec:PASSWORO  =  password  ) ; 
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11.1 .5  •  •  •  Interface  with  user  •  *  • 
demon  USER-INTERFACE(commands) 

trioaer  •  •  •  Place  here  user  activity  to  provide  commands  and  initiate  processing  *  •  • 
response  SOURCE-DATA>MAINTENANCE(commands) ; 


11.1 .6  •  *  •  Actions  to  perform  commands  *  *  * 


11.1.6.1  •••  SOURCE-OATA-MAINTENANCE  •** 

action  SOURCE-DATA-MAINTENANCEfcommands  I  sequence  of  command! 
definition 

over  commands  named  com 
do  attempt 
case  com  of 

update-command  =>  UPDATE[com]; 
copy-file-command  =>  COPY-FILE[com], 
backup-command  =>  BACKUP[com]; 
restore-command  =>  RESTORE[com]; 
end  case : 


•a. 

1. 


11.1.6.2 


UPDATE 


action  UPDATE[updete-command] 

IfilWe  =  i;pctefecommand:CURRENTFiLESPEC:FiLE 
definition 

over  uodafe-command.UPDATE-SUB-cOMMAisiDS  named  uo-com 
do  begin 

require  3  current-unit  |  essence  fif  unit  ||  current-unit  =  up-com;CURRENT-UNiT; 
gtt,empt 
case  up-com  Qf 

add-command  =>  ADD[ct/rrenf-un/r.f/7e,£/p-com]; 

purge-command  =>  PURGE[currer)r-un/f]; 

replace-command  =>  PBPLACE[current-unit,iile,up-com]; 

copy-unit-command  =>  COPy-UH\T[current-unit,file,up-com]- 

change-command  =>  CHAHGE[current-unit,up-com]\ 

end  case 
end  ; 


11.1.6.3  "  •  ADD  ••• 

action  ADD[un<r  |  essence  pf  unit,  tile,  add-comrr.and] 
definition 
begin 
atomic 

create  unit,  copy-ot-Hnes  ( sequence  cf  line  j| 

copy-of-lines  =  add-command.DkJ k  A 
un;7:UNlT-CONTENTS  =  copy-ot-lines\ 
insert  f//e:uN(T  =  unit 
end  atomic: 

if  3Ae/l|/<eK  =  add-ccmmandiUNiT-KEY  then  insert  un/t:UNiT-KEY  =  key 
end ; 
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II. 1.6.4  •••PURGE  ••• 

action  PURGE[i/n/l] 
definition  destroy  unit ; 


II.  1.6.5  •••REPLACE  ••• 

action  REPLACE[un/r  I  essence  of  unit,  file,  replace-command] 
let  data  I  sequence  of  line  *  replace-command-.DAi/k 
definition  *  •  •  If  referenced  unit  already  exists,  replace  its  contents, 
otherwise  create  a  new  unit.  •*  * 

if  3  unit 
then  begin 

create  new-lines  |  sequence  fit  line  H  new-lines  s  data: 
update  :UNiT-coNTENTS  Qf  unit  la  new-lines 

end 

else  begin 

create  add-command  II  add-command:DATA  b  data; 
ADDlunit.fiie,add-command] 
sndi 


11.1.6.6  •••  COPY-UNIT  •*• 

action  COPY-UNIT[un/f  I  essence  of  unit,  file,  copy-unit-command] 
definition 
etomic 

create  unit  ||  unit  =  from-unit', 
insert  ffle.UNiT  =  unit 
end  atomic : 


I 


11.1.6.7 


CHANGE 


action  CHAHGE[unil.changB-command] 
definition 

over  cftange-command.CHANGE  SUB  COMMANDS  named  ch-com 
do  attempt 
case  ch-com  gf 

insert-command  =>  INSERT[L/n/f,ch-com]; 
delete- command  =>  DELETE[unif,cf)-com]; 
shift-command  =>  SHIFT[ch-coml; 
modify-command  =>  MODIFY[cAj-com]; 
copy-lines-command  =>  COPY-UNES[un/t.ch-co/n]; 
replace-line-command  =>  REPLACE-LINE[un/t, ch-com]; 
end  case  : 


11.1.6.8  INSERT  ••• 

When  inserting  lines  into  a  unit,  we  may  either  explicitly  say  where  the  insertion  is  to 
take  place,  or  by  default  let  the  lines  be  inserted  after  the  last  position  of  change  to  that 
unit  (during  the  cur-ent  CHANGE  command),  or  at  the  start  of  the  unit  if  there  has  been  no 
such  change. 

To  find  the  last  position  of  change  we  define  two  relations.  LATEST-STATE-OF- 
CHANGE(unit, state)  relates  a  unit  to  the  latest  state  (since  starting  execution  of  CHANGE) 
at  v/hich  the  unit  contents  then  differ  from  the  unit  contents  now.  LATEST-POSITION-OF- 
CHANGE  relates  the  unit  to  the  position  of  this  change. 


relation  LATEST-STATE-OF-CHANGE(UNtT  ,  changestate  \  state) 
definition 

changestate  *  latest  some  state  ||  on/f '.unit-contents  ~s  (  umf.UNiT-coNTENTS  ^fif  state  )  A 
state  after  latest  start  CH  ANGE[un/t,$] ; 
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relation  LATEST-POSITION-OF-CHANGE(un/f ,  sequence-/ocaf/on) 
definition 

3  changestale  1  state,  longest-same-bollom  |  sequence  Qf  line  || 

longest-same-bottom  *  longest  some  same-bottom  sequence  of  line  II 
LATEST-STATE-0F-CHANGE(un/t.c/)8nqesfaJe)  A 
un/f;UNiT  CONTENTS  =  $  @  sequence-tocation  @  same-botlom  A 
( unir:uNiT-C0NTENTS  ssQfc/Jangesfafe )  «  $  @  sequence-location  @  same-bottom 


action  INSERT[un/f,  insert-command] 
let  data  =  insert-command.DAT^ 
definition 

if  3  sequence-location  ||  sequence-location  =  mse/T-commandiSEOUENCE-LOCATiON 
then  POSITIONED-INSERT(un(f,c-:-fa.sequence-/ocaf/on] 
else  UNPOSITIONED-INSERT[un(7,qafa] ; 


action  POSITIONED-INSERT[un/(.  data  I  sequence  of  line,  sequence-location] 
precondition  3  topseq  |  sequence  fif  line,  bottomseq  |  sequence  fif  line  |1 

■  un/f;uNiT  CONTENTS  »  topseq  @  sequence-location  @  bottomseq 

definition 

begin 

create  new-lines  1  sequence  Qf  line  ||  new-lines  s  data; 
update  ;UNIT.C0NTENTS  fif  unit  topseq  @  new-lines  @  bottomseq 
end  ; 


action  UNPOSITIONED-INSERT[ur7(?, data  I  sequence  of  line! 
definition 
begin 

create  new-lines  1  sequence  j^f  line:  ||  new-lines  h  data; 
update  ;UNIT-C0NTENTS  sjf  unit 

12  { if  3  topseq  |  sequence  fif  line,  bottomseq  j  sequence  al  line,  sequence-location  || 
LATEST-POSITION-OF-CHANGE(un/t,sequence-/ocaf/on)  A 
un/t:UNiT-CONTENTS  =  topseq  (§  sequence-location  @  bottomseq 
then  topseq  @  new-lines  @  bottomseq 
else  •  •  •  if  unit  as  yet  unchanged,  insert  at  front  *  *  * 
new-lines  @  un/f:UNiT-CONTENTS 

) 

find ; 


11.1.6.9 


DELETE 


action  DELETE[on/t,  delete-command 

precondition  3  startseq  I  sequence  flf  line,  endseg  ]  sequence  jjf  line  || 

un/f:uNiT. CONTENTS  *  siartseq  @  delete-command'UUES  @  endseq 

definition 

update  iUNiT  cONTENTS  Qf  unit  ia  startseq  @  endseq 


11.1.6.10 


SHIFT 


action  SHIRT[srt/ff-command] 
definition 

over  shitt-command:UNZS  named  line 
£lfi  update  .CHARS  af  line  la 

some  newchars  sequence  of  character  || 
\SSH\EJEO(newchars,chars,shift-command:columns) ; 


relation  1SSHIFTED(newchars  |  sequence  al  character, 

OLDCHARS  I  sequence  of  character.  columns  to-Shift  [  integer) 
definition 

3  old-leit-blanks  I  sequence  of  "  ",  old-riaht-blanks  I  sequence  of  "  ", 
new-lett  btanks  |  sequence  al  "  ">  new  right-blanks  \  sequence  a!  " 
non-blanks  I  sequence  of  character  || 

~MEMBER(non-£)/ani(s  A 

oldchars  =  old-left-blanks  @  non-blanks  @  old-right-blanks  A 
newchars  »  new-left-blanks  @  non-blanks  @  new-right-blanks  A 
\sn3ib[new-lef1-blanks)  -  \er\a\U(old-left-blanks)  =  columns-to-shiit ; 


••*  e.g.  <  "A"  ,  "B"  ,  "C"  ,  "  "  ,  "  '*  >  may  be  shifted  by  2  columns  to  give 

<  ..  ..  ^  ^  „Q..  Uf..,  y 

<•'  ■■  "  ,"A"  ,"B"  ,"C"  ,”  ">  or 

”A" ,  "B" ,  "C"  ”  ”  >  etc. 
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11.1.6.11  •••  MODIFY  ••• 

action  MOD\PY[modify-con)mand] 
let  lines  I  sequence  of  line  =  modify-command.UNB& 
let  new-slrina  I  sequence  of  character  =  mocf/fy'-commantfiNEW-STRiNG 
definhion 
begin 

if  3  starting-column  \  integer  ||  starting-column  =  /nddify-commandiSTARTiNG-coLUMN 
then  over  lines  named  line  jjg  MODIFY-BY*COLUMN[//ne,sfarf;V7p-co/umn,new-s/r/ng]; 

if  3  old-string  I  sequence  ofcharacter  1|  old-string  =  mod/7y-command:OLD-STRiNG 
then  over  lines  named  line  MODIFY-BY-REPLACEMENT[//ne,o/d-str/np,nen'-sfr/ng] 
gn^i; 


action  MODIFY-BY-COLUMN[//ne,  starting-column  |  integer,  new-string  I  sequence  of  character] 
definition 

update  ;CHARS  gf  line 

ifi  ( from  1  bv  1  while  <  starting-column  named  / 
obtain  MEMBER(//ne:CHARS,/,’) )  @ 
new-string  @ 

I  from  starting-column  +  lenathfnew-str/no)  4  1  fcy  +  1  while  »  <  lenQth(//rie:CHARS) 
named  i  obtain  MEMBER(//ne:CHARS.<.*) ) ; 


action  IViODIFY-8Y-REPLACEMENT[//ne,  old-strina  I  sequence  of  character. 

new-string  |  sequence  Qf  character] 

definition 

if  //neiCHARS  =  $  @  old-string  @  $ 
then  update  :chars  gf  line 

ifi  some  newchars  I  sequence  of  character  || 
newchars  @  S  = 

REPLACE-ALL-INSTANCES(c/iars,o/d-s(nng,new-srn>?g)  @ 

some  biank-seq  \  sequence  lal  " 


function 

REPLACE- ALL-IKISTANCESfchars  I  sequence  of  character,  old-string  I  sequence  of  character. 
new-string  I  sequence  of  character) 

if  3  leftchars  I  sequence  of  character,  rightchars  I  sequence  of  character  || 
chars  =  leftchars  @  old-string  @  rightchars 
then  REPLACE-ALL-INSTANCES(/e/;chars,o/d-str/np,new-sfr/np)  @  new-string  @ 

REPLACE- ALL-INSTANCES(r/ghtc/iars,o/d-sfr/np.neiv-sfrmg) 
else  chars  ; 


11.1.6.12  •••  COPY-LINES 


action  COPY’UNES[unit,copy-/ines-command] 
let  //nes  I  sequence  of  line  =  copy-lines-command.LiUES 
precondition  copy-Z/nes-command.-FROMUNiTrUNiT  CONTENTS  ■  $  @  lines  @  $ 
definition 
begin 

require  3  sJanseq  |  sequence  of  line,  endseq }  sequence  Qf  line  || 
un/'t:UNiT-coNTENTS  *  stariseq  @  sequence-location  @  endseq, 
create  new-lines  |  sequence  flf  line  ||  new-lines  s  lines; 
update  :uNiT-C0NTENTS  fif  unit  ic  startseq  @  ( new-lines  )  @  endseq 
£n^^; 


11.1 .6.1  3  *  REPLACE-LINE  *  *  * 

action  REPLACE-LINE[un/f,  replace-line-command] 

precondition  MEM  B£R(un//:uN(T-coNTENTS,$,rep/ace-//ne-command;OLDLiNE) 
definition 

update  .UNIT-CONTENTS  flf  unit 
12  tun/f:uNiT  CONTENTS  named  line 

obtain  ( if  tine  =  oldline  then  newline  else  line  ) ) ; 


11,1.6.14  ***  COPY-FILE  **• 


action  COPY -FiLElcopy-lile-command] 

IgfWe  =  copy-file-command:70-FiLZSPEC:F\Le 

IgJ  from-We  I  file  =  copy-We-commandiFROM  FitE  SPECiFiLE 

definition 

over  from-tiie:UNir  named  from-unit 
atomic 

create  new-unil  \  unit  ||  new-unit  =  from-unit; 
insert  f;'/e:UNiT  =  new-unit 
end  atomic : 
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11.1 .6.1 5  •  •  •  BACKUP  and  RESTORE  *  *  * 

action  BACK[JP[backup-command]; 

*  *  *  Simply  activating  BACKUP  with  its  parameter  suffices  to  serve  as  an  event  that  we 
may  later  refer  to  in  a  RESTORE  command. 


action  RESTORE[res(ore-command] 

let  obi  I  essence  of  project  U  library  U  file  U  unit  =  resfore-command:OBjECT 

precondition  *  *  *  A  backup  must  have  been  performed  at  the  time  specified  in  the  restore 
command  and  the  object  being  restored  must  have  been  the  object  (or  part 
of  the  object)  backed  up  at  that  time.  •  *  * 

3  backup-command  H  restore-command.BACKUP  ST ATE  =  start  BACKUPfbac/tuD-command)  A 
( backup-command:OBJECr  contains  obj )  ag  gf  res(ore-command:BACKUP-STATE 


definition 

restore  obj  as  gf  resfore-command:BACKUP  STATE; 

**•  Note  that  because  RESTORE  commands  refer  only  to  times  at  which  BACKUP 
commands  were  executed,  the  implementor  need  only  allow  for  restorajtion  to  such  points 
in  time  rather  than  to  arbitrary  points  during  the  past  execution. 


) 
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II.  1.7  •••  Restoration  following  temporary  changes 

demon  TRIGGER-TEMPORARY-RESTORATION(evenf) 

•  *  *  At  end  of  job,  trigger  restoration  of  units  temporarily  changed  during  job  *  *  * 

triooer  -  SOURCE-DATA-MAINTENANCEl$] 
response  RESTORE-UNITS-TEMPORARILY-CHANGED-SINCEI 
latest  start  SOURCE-DATA-MAINTENANCE[i;] ; 


relation  TEMPORARY-CHANGE-BEGAN(un/f,sfa/e) 
definition 

3  tc-com  I  temporary-change-command  II  start  CHANGEfLin/t-te-com]  >  stale 


action  RESTORE-UNITS-TEMPORARlLY.CHANGED-SINCE[s  state] 

•  *  *  Action  to  do  restoration  of  all  temporarily  changed  units  to  the  state  they 
were  in  prior  to  their  first  temporary  change  since  state  s  *  *  * 
definition 

over  state  named  sT  when  sT  «  earliest  some  state  l(  state  after  s  A 
(  3  unit  II  TEMPORARY-CHANGE.BEGAN(un/f, state) ) 
do  restore  unit  as  of  s  7  ; 


always  required  PRESERVE-ABILITY-TO-RESTORE-TEMPORARILY-CHANGED-UNITS 

***  When  executing  SOURCE-DATA-MAINTENANCE,  must  always  be  able  to  restore 
temporarily  changed  units  so  that  the  actual  restoration  occurring  at  the  end  of  the  job  will 
not  be  anomalous. 

mm* 

SOURCE-DATA-MAINTENANCE[$)  => 
admissible  RESTORE-UNITS-TEMPORARILY-CHANGED-SINCE[ 
latest  start  SOURCE-DATA-MAINTENANCE[$] 
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11.1 .8  *  *  *  Maintenance  of  information  about  units  *  *  * 


•  •  *  According  to  the  English  specification  many  items  of  information  about  units  are  to 
be  kept  within  the  unit  accounting  record.  Using  the  specification  language  we  are  able  to 
derive  such  information  rather  than  explicitly  assigning  it  to  the  units  as  they  are  created. 
To  demonstrate  how  this  is  possible,  we  retain  two  such  pieces  of  information  associated 
with  units,  programmer  and  source-lar>guage,  and  show  how  these  may  be  derived. 


derivation  DERIVE-UNIT-PROGRAMMER(on//) 
whenever  3  programmer  II  programmer  s  (  PROGRAMMERfSi  as  of  create  unit ) 
conclude  un/'/.PBOGRAMMEfi  =  programmer  ; 

•••  PROGRAMMER($)  is  assumed  to  be  a  unary  relation  provided  by  the  operating 
environment  returning  the  programmer  submitting  the  current  job. 


derivation  DERIVE-UNIT-SOURCE-LANGUAGEfun/f) 
whenever  3  language  || 

(  3  add-command  II  adc'-commanof-.souRCE-LANGUAGE  =  language) 
as  of  latest  start  ADD[umr,$, add-command) 
conclude  un/f:S0URCE-LANGUAGE  =  language  ; 
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11.2  HOST-IMP  SPECIFICATION 

HOST  IMP  PROTOCOL  specified  in  Gist 


Contents 

General  features  of  host- imp  world 
Modes 

Hardware  failure 
Specialization  to  hosts  and  imps 
Interface  with  external  world 
Hosts 
Imps 


•  General  festures  ========================  ••• 

Objects  of  type  item  are  transmitted  between  nodes.  Relation  CONNECTED  indicates 
which. nodes  are  connected  for  transmission. 


type 

item(MesSAGE  ,  ADORESS  (  node); 


ralation  CONNECTED(node  ,NODE) ; 

always  prohibit  SELF-CONNECTEDNESS 
3  node  ||  CONNECTED (nooe, node); 


NODES 


Modes  are  agents  which  perform  transmissions.  Hosts  and  imps  will  be  specializations  of 
these  Modes  have  several  groups  of  items  or  messages  associated  with  them: 

PEWDiNG  •  items  yet  to  be  dealt  with  by  the  node 

TO  BE  SENt  ■  items  to  be  sent  elsewhere 

Mv-MESSAGES  •  messages  from  items  addressed  to  the  node 
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agent  node(  pending  :  any  ]  Item  , 

TO-BE-SENT  rAny  |  Item  .  mv-messages  :any  |  message)  with 


action 

TRANSMIT[/fem  ,  fo  |  node] 

precondition  CONNECTED  fsetf*  .fot 

•••  Within  context  of  definition  of  agent, 
•setf*  used  to  refer  to  that  agent.  ••• 
•••  Invoking  TRANSMIT  serves  as  an  observable  event, 
so  this  action  needs  no  body  •••;. 


pending-demon  RECElVE(//em  ,  evenf ) 

•••  Watch  for  transmissions  to  this  node. 

tr  iooer  started-eventf  e^enf)  A  event  =  TRANSMIT ( Hem .  •sell*  1 
begin 

wait  until  (  f i ni shed- event! events  V  abo r ted -events event  1  ); 
i_f  finished-eventf event)  •••  i.e.  transmitter  remained  OK  ••• 
then  insert  item  into  *se/t* ; pending 
end : 


pend  i  ng-demon  PROCESS-PENDING((tem) 
triooer  item  -  *seli* :  pending 
response 
begin 

delete  •self*  :  pending  =  item ; 
if,  (fen?:  ADDRESS  =  *se/f* 
then  insert  *seH* :  my-messages 
el  se  insert  •sell*  : TO-BE-SENT  = 


end: 


=  (fern :  message; 
item 


acfi.a.r^ 

ACTIVATE[]  •••  This  action  is  invoked  when  the  agent  is  activated  ••• 
def inition 
begin 

delete  al  1  •self*  :to-be-SENt  =  $; 
delete  al  1  •§eft*: pending  =  $; 
wait  Relay-Set-Time ; 

find 


end  agent 
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•  •• 


Hardware  Failure 


agent  hardware  failure  with 

***  Node  hardware  failure  is  modelled  by  the  following  demons,  which  at  random  deactivate 
and  reactivate  nodes. 


demon  NODE-HARDWARE-FAILURE 
tr iooer  random 

response  deactivate^some  node  ): 

demon  NODE-HARDWARE-RECOVERY  (node) 
tr iooer  random  A  Tacti ve(node) 
response  acti vatefnodel 

end  agent: 


Specialization  to  host-imp  world  ========*=*=====  ••• 


*"  Hosts  and  imps  are  specializations  of  nodes.  Messages  specialize  to  user-messages, 
acknowledgments  (of  user  messages,  when  they  reach  the  imp  connected  to  the  destination 
host),  and  host  going-down-messages  (which  a  host  sends  to  its  imp  to  indicate  it  is  being  turned 
off). 


agent  node  superaaentof  <  host  ,  imp  >  end  aoent 

type  message  supertvoeof  <  user-message  ; 

acknowledgments ( ACKNOWLEDGES  |  item)  ; 
hosl-dead  acknowled9ment5( ACKNOWLEDGES  |  item)  ; 
host-going-down-message  >  ; 


always  prohibit  DIRECT-HOST-CONNECTIONS 

3  host.!,  host.  2  |f  CONNECTED  ( hosM  ,  hosf .  2 )  ; 


INTERFACE 


*•*  We  model  the  user  interface  and  possible  interactions  on  our  host-imp  world  by  defining 
two  demons,  USER-SEND  to  create  and  send  a  user-message  to  some  host,  and  USER-TURN¬ 
OFF-HOST  to  turn  off  a  host. 


.  ^ 

•  1 
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a9ent  interface  with 

demon  USER-SEND 
tr iooer  random 
response 

create  user-message ,  item  1 1 

rfe/n;  MESSAGE  =  user-message , 
/Yem: ADDRESS  =  some  host; 
insert  ( some  host)  ;TO-be-SENT  =  Hem 
end: 


demon  USER-TURN-OFF-HOST 
tr iooer  random 
resePQje 
teSfllQ 

reou i  re  3  host; 

create  host-going-down-message , 
item ;  message 
item  :  ADDRESS 

insert  hosf ; TO-BE-SENT  =  item 


£M 


item  I  I 

=  host-going-down-message , 
=  hosf:  CONNECTED- IMP; 


£ni  agent 

•  «  • 


HOSTS 


*•*  Hosts,  being  subagents  of  nodes,  inherit  nodes  definitions;  in  addition  they  have  the 
following; 


agent  host  (connected-imp  )  imp)  with 

always  reoui  re  V  host,  imp  \  ] 

host :CONNECTED-iMP=/mp  CONNECTED ( hosf,/mp ) 

i=»  CONNECTED  (imp,  host) 


pend  i  ng-demon  SEND  (item) 

trigger  Hem  -  *se/f* : TO-BE-SENT 

response  TRANSMIT[;fem  ,  *se/f* :C0Nnected-imp1 


end  agent 
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IMPS 


Imps,  being  subagents  of  nodes,  inherit  nodes  definitions;  in  addition  they  have  the 

following; 

%  •  • 


agent  imp( dead-hosts  :anv  |  host)  with 

*••  Attribute  ;0EAD-H0STS  used  to  record  which  of  the  connected  hosts  are  considered  to  be 
■'dead”  by  the  imp. 


•**  One  event  which  causes  an  imp  to  mark  a  connected  host  as  "deaa"  is  receipt  of  a  host¬ 
going-down-message.  "** 

demon  MARK-HOST-DEAD(/Jost ,  host-going-down-message) 
trigger  hos/ :  connected- imp  =  •££//•  A 

(  hosf-go/ng-down-message MESSAGE  =  •££//•:  pending  A 
creator- of  host-going-down-message  =  host  )  V 
lacti ve(nosf1  ) 

response  insert  •sett*  :  dead-hosts  *  host-. 


Successful  receipt  of  a  message  from  a  connected  host  (other  than  a  host-going-dow-n- 
message)  will  cause  the  host  to  be  removed  from  those  marked  as  dead.  •** 

pendino-demon  UNMARK-KOST-DEAD(nosf .  ifem) 

tripoer  1  ( /fern  : message  1  sa  host-going-down-message)  A  Hem  =  •sell*  :  pending  A 
host  =  aoent-of (  1  atest  TRANSMIT(/tem  ,  *sel(*  1  ) 
response  delete  •5£//*  :  DEad-hoSTS  =  host; 

pendino-demon  SEND  (item) 

triage  item  =  *se/f*  :  to-be-SENT 
response 
begin 

delete  •ge/f*  :TO-BE-Sent  »  item; 
vf  CONNECTED  (•seif*  .  /fern :  ADDRESS ) 
then  if  ifem ; address  isa  host 

then  if  /fern:  address  1=  ;  dead-hosts 
then  begin 

TRANSMIT[(fem  .item  :  ADDRESS] ; 
if  /fern: MESSAGE  isa  user-message 
then  ACKNOWLEDGE-OK[ifem] 
end 

else  if  item: MESSAGE  isa  user-message 

then  ACKNOWLEDGE-DEAD[/fem]: 
else  TRANSMIT[/rem  , /fern :  ADDRESS] 

else  TRANSMIT[/fem,$] 

•••  Send  item  onwards  through  network.  ••• 
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CIST  SPECIFICATIONS 


oend  1  no-demon  RECEIVE(/fem ,  evenf) 

***  Specialize  definition  of  receive  for  imps  to  terminate  wait  for  a  message  if  more  than  15 
seconds  have  passed  since  start  of  receipt.  **  * 

trigger  started-eventf  eventl  A  event  =  TRANSMIT( /fern, node) 
resncr:e 
^y-^in 

wait  until  (  f ini  shed -even tf event  1  V  aborted-event  f  event)  V 

duration (event)  >  15  seconds  ); 
if  f  ini  shed -event f  event  1  then  insert  *£g/f*  :  pending  =  item 
end : 


oend  i  no-demon  PROCESS-MY-MESSAGES(message ) 
tr  iooer  message  =  *selt*  :MV-MESSAges 
response  delete  *se/f*  : my -messages  =  message: 

**•  Imps  simply  discard  messages  addressed  to  themselves.  ••• 


action  ACKNOWLEDGE-OK[/tem] 
def  inition 
'bee  in 

create  acknowledgments ,  reply  |  item 

II  acAnow/edgments : ACKNOWLEDGES  =  item, 
rep/y:  MESSAGE  =  acknowledgments, 
rep/y:  ADDRESS  =  creator-off  item) : 
insert  reply  into  *se/f* :T0-BESENT 
end : 


action 

ACKNOWLEDGE-DEAD[/rem] 
def inition 
begin 

create  host  dead-acknowledgments ,  reply 

II  tJost-dead-acAnow/edgments :  ACKNOWLEDGES  =  item, 
rep/y:  MESSAGE  =  host-dead-acknowledgments , 
rep/y;  ADDRESS  =  creator-of  (item) : 
insert  ‘se//* : TO-BE  SENT  =  reply 
end : 


demon  C0NNECTED-H0ST-G0NE-D0WN(/7OSt) 

•••  What  to  do  when  a  connected  host  goes  down.  ••• 
trioger  host : CONNECTED  imp  =  •££//•  A  Tacti ve f host) 
response  DEADIFY[t70St] 


end  demon 
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action 

DEADIFY  [rtosO 
def inition 
beg  i  n 

delete  a1 1  ‘se//*  :to-be  sent  =(  some  item  ||  /fern:  address  =  host  )  ; 
unschedule  a1 1  [  SEND  (/fern)  |  |  /rem:  address  =  host  ] 

end : 


demon  TARDY-SEND-QUEUES  (/(em.hos/) 

•••  What  to  do  if  send  queue  not  emptied  rapidly  enough.  ••• 
trigger  /lem:  ADDRESS  =  host  A  hosJ ;  CONNECTED- IMP  =  ‘gg/f*  A 
durationf  item  =  •self* : to-be-sent  )  >  30  seconds 
response  DEADIFY[/70sf] : 
end  agent 


11.3  FORMATTER  SPECIFICATION 
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bound  equiv  by  =  :  header<-t i tie , 

=  :footer*-title. 

=  :  left<-margin. 

=  :subsequent«-left<-mar9in. 
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MISSION 

of 

Rome  Air  Development  Center 

KAOC  plani  and  execatei  tieAeoAch,  development,  test  and 
Aelecked  acquisition  ptiogaams  In  support  o^  Command,  Contfiot 
Communications  and  Intelligence  IC^I)  activities.  Technical 
and  englneeAlng  support  volthln  aneaus  oi  technical  competence 
Is  provided  to  ESV  Ptiogaam  O^^lces  {POs)  and  othe/i  ESP 
elejnents.^  The  ptUnclpal  technical  mission  oAeas  one 
communications,  etectkomagnetlc  guidance  and  contKol,  suti- 
veillance  oi  gtiound  and  aerospace  ob/ects.  Intelligence  data 
collection  and  handling,  In^otimatlon  system  technology. 
Ionospheric  propagation,  solid  state  sciences,  mlcaomve 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


